Scott> * %hash`s is an example of a small thing that would be easy to implement
Scott> in core but would be used constantly (if JavaScript is any indication,
Scott> every few lines), giving a lot of bang for the buck
Not sure that JavaScript is relevant here, since the "equivalent"
syntax there, ".", is the same as the method call syntax. But see my
proposal below.
Austin> I don't like it visually, and I'm too used to ` as a quoting character
Austin> to feel comfortable with this usage.) Also, this reminds me of the
Austin> old namespace syntax: $package'var. I'm glad that's gone, too.
I agree on all counts.
Scott> Rather than eliciting public comment on %hash`foo (and indeed
Scott> %hash<<foo>>) the proposal is being rejected out of hand
? Who has rejected it out of hand? And what is this entire thread if not
"eliciting public comment"?
If I might offer a modest counter-proposal - how about a fallback method
(the equivalent of Perl5's AUTOLOAD or Ruby's method_missing, however
that winds up being spelled in Perl6) that would return the value of the
key equal to the requested method name? Actually, it should return it
as an lvalue to allow the shortcut to be used in assignments. This
wouldn't need to be in the Hash base class; it could be in a subclass
called RhinoHash or some such. Then %hash{'foo'} == %hash«foo» could
also be spelled %hash.foo, as long as 'foo' weren't the name of a hash
method - just as in JavaScript.
It wouldn't work for non-literals, though, unless $obj.$var is going to
be legal for "invoke the method whose name is in $var on receiver $obj", which
I don't think it is. But given the need to avoid conflicts with
defined methods, having it work for non-literals would be more problematic
anyway.
-Mark
