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]