1. You're talking about objects. Objects have methods. You cannot use the indirect dereference with methods. So, now you have one syntax for getting values from the object and another to call methods. Much better is to have one syntax for both. (This is why Perl4 uses that indirect dereference and Perl5 uses the arrow. But, Perl5 is backwards compatible ...)
2. $$object is the syntax for soft references. That is the only way to do soft references. So, whenever I (your doughty maintenance programmer) see that syntax, I start thinking about why you want to have a soft reference there. But, you don't have a soft reference there. You're using cargo-cult programming learned from someone who never made the jump from Perl4 to Perl5. This is confusing. You could have made it clear that there is no soft reference.

   (Soft references are not always bad ... but you shouldn't use them until you know why they are always bad.)

Update: Fixed mistaken notion re: symbolic references. (Thanks, tye!)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

$$object is the syntax for soft references. That is the only way to do soft references.

No, that is just dereference syntax and it and $object-> both do exactly the same thing whether $object contains a hard reference or just a variable name ("soft reference").

                - tye

You're talking about objects. Objects have methods. You cannot use the indirect dereference with methods. So, now you have one syntax for getting values from the object and another to call methods.

This makes good sense. I think I know why I missed it up to this point: none of the objects I've written in Perl as yet has needed any routine properties. In the language where I have written objects complex enough to need them, references are handled somewhat differently. (Depending on how you view it, either there's no such thing as a reference, or else references are the only way to refer to any data type besides integers.) So the direct syntax, foo.bar or foo.bar() works for both. (In fact, foo.bar() will DTRT if the bar property is a reference to a string instead of a reference to a routine. This is useful because in Inform routines and strings are in many cases interchangeable from the caller's perspective; the difference is an implementation detail of the object.) But I can see that if ${$foo{bar}}() won't do the right thing in Perl, then for consistency I should use the other syntax. [Jonadab idly wonders for a moment about &{$foo{bar}}() but then thinks better of it.]

So, whenever I see that syntax, I start thinking about why you want to have a soft reference there.

But surely if I were using strict, you could easily dismiss that thought.

You're using cargo-cult programming learned from someone who never made the jump from Perl4 to Perl5.

I'm not certain where I picked it up, but if I had to guess my first guess would be the Camel; most of the Perl I know I learned from that book (2nd ed). But the reason I liked it is because it makes sense: it looks like a dereference. Conceptually, it's a natural extension of Perl's other syntax. The arrow syntax I've never liked; it comes from languages with really lousy OO models, such as C++. Perl is the only language I ever liked that allows it. The syntax I want is the foo.bar syntax...

sub moveto {
  my ($p, @ch) = @_;
  foreach $c (@ch) {
     $c.parent = $p;
     push @p.children, $c;
     $c.siblings = (listsubtract(\@ch, [$c]);
  }
}
[download]

I guess I'll have to wait for Perl 6 for that.

(Soft references are not always bad ... but you shouldn't use them until you know why they are always bad.)

I'm careful about soft references. I don't use them with wild abandon. I have been known to do something like the following (where $r comes from a DBI fetchrow query) ...

foreach $f ('foo', 'bar', 'baz', 'wibble', 'tlee') {
   $$f = $r->{$f};
}
[download]

But that's very localised and controlled; $f is not set in some far-off location, calculated by a subroutine from another module, entered by a remote user on the web, extracted from a file by a regex, or autovivified by the assignment. (In that case, it would be $input{$f} instead of $$f -- I'm not entirely without a modicum of sense.)

---

sub H{$_=shift;while($_){$c=0;while(s/^2//){$c++;}s/^4//;$
v.=(' ','|','_',"\n",'\\','/')[$c]}$v}sub A{$_=shift;while
($_){$d=hex chop;for(1..4){$pl.=($d%2)?4:2;$d>>=1}}$pl}$H=
"16f6da116f6db14b4b0906c4f324";print H(A($H)) # -- jonadab
[download]

Uhm, strict will catch any and all attempts to use symbolic references - regardless of whichever syntax you use.

Makeshifts last the longest.