Yes, think of a reference as a pointer
My understanding of the reasoning behind the name is that a reference is supposed to keep track of what it points to and garbage collect it if needed. Perl does that. Therefore it isn't a pointer and shouldn't be called on.
As for whether a reference should look like what it is pointing at, I'd call that choice consistent with Perl's design. Think C for a second. Suppose that foo is a struct and bar a pointer to foo. You can access a field baz in the struct either through foo.baz or bar->baz.
Let's carry this analogy through to references and OO syntax. If you think of objects, etc as immediate, then a C-trained person would be inclined to use the . notation. Unfortunately Perl had already used . for string concatenation and so in Perl 5 they didn't want to use it for method calls etc. However for a C-trained person it makes just as much sense to say that there is a level of indirection visible everywhere, and you use -> instead. Which is
exactly what Perl did. You access things through a reference using the notation that you would for a pointer in C, and this notation is used for method calls as well.
The idea of this indirection goes surprisingly far. Take, for instance, the following:
\nmy $bar = my $baz = bless {}, 'Package::A';\nbless $bar, 'Package::B';\nprint ref($baz); # prints Package::B\nWhat happened is that since an object is a blessed reference, and everything OO in Perl happens through a layer of indirection, the package an object belongs to is stored on the data that is object, not in the reference pointing to the object. So the effect of calling bless on one reference to the object is visible from every other copy of said object.
Unfortunately for Perl, nobody else made that design choice. So as reasonable a choice as it may have seemed when it was made a decade ago, it causes pain and confusion now. Which is why Perl 6 (whose syntax is deliberately
not backwards compatible with Perl 5) will reverse that choice.
Cheers,
Ben
