Michael G Schwern wrote:
>
> > sub lock { print "Hello!" }
> > $trans = new Lock::Ness;
> > lock $trans; # $trans->lock
>
> That's not right.
You're correct. Sorry for not double-checking my examples.
> the same reasons I've already pointed out. You don't want adding a
> method to a class to suddenly alter the behavior of distant code.
Regardless of my huge error above, this doesn't change the fact that
this is exactly what tie() does currently in Perl 5. That is:
tie @a, 'Matrix';
push @a, $stuff;
Now changes the meaning of push() in the current package. So the only
real difference in this situation from a user standpoint is that "PUSH"
becomes "push" per the RFC, plus they can now do this with any function
they please.
> Yes, it does help solve those problems. The dangling untie() will
> happen less frequently, and you can customize the hell out of your
> tied class. But you're trading those problems for a new set of
> ambiguities!
I think your concerns are worthwhile. However, I think the "ambiguities"
part can be resolved through precedence rules and similar constructs. I
think there are many more potential upsides than downsides I<assuming a
careful implementation>. By v2 I expect to have a considerably better
implementation section, complete with examples, specific code, rules,
and so forth that should help alleviate any potential ambiguities.
Also, little attention has been paid to operator overloading, which is
another huge deal. Per this RFC, we can now integrate operator
overloading and higher-order variables like @ and %, meaning we can add
custom matrix math classes, special %hashes that do neat stuff in string
contexts, and more.
-Nate
