Re: ./method defunct
John Siracusa wrote: On 6/18/05 8:28 PM, Juerd wrote: The unix shell and things resembling it will still be in use much fifteen years after today, Perl 5 will not. Ooo, a bold prediction :) Heh, it is indeed. And it means given the 16,000,000 lines of Perl in CPAN, we only have to keep the porting rate up at around a million lines of code a year. Adam K
Re: ./method defunct
On Jun 18, 2005, at 9:24 PM, Damian Conway wrote: chromatic wrote: I find it ugly enough that I plan to name my invocants explicitly. ...which should be construed as a *feature* of the current syntax. ;-) Damian In that case, why do we have this feature? Seriously. Are default invocants really such a good idea? At least, do they need to be there in 6.0.0? Do they need to be supported in the core engine, or could they be pushed out to a module? I guess that as long as we're arguing the color, we might as well argue the location of the bikeshed. All that said, I still agree with John... './' does not look like method call syntax to me. But, whatever. I suppose I'll get used to this, along with all the other things that have given me the heebie- jeebies so far. :/ --Dks
Re: ./method defunct
David Storrs skribis 2005-06-19 13:45 (-0400): Seriously. Are default invocants really such a good idea? Yes, as long as the default is $_. ./method doesn't use a default invocant. It calls method on the current invocant, which happens to be available as $?SELF: that doesn't mean it defaults to $?SELF. The term default is inappropriate if there is no way to specify anything else: $object./method is still invalid syntax. All that said, I still agree with John... './' does not look like method call syntax to me. That's good, because it's different from all other method syntax anyway, because it does not have any left hand side -- not even implied. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
AUTLOAD and $_
From S10; In any case, there is no longer any magical $AUTOLOAD variable. The name being declared or defined can be found in $_ instead. The name does not include the package name. You can always get your own package name with $?PACKAGENAME. So, what is the prototype of AUTOLOAD? It is clearly called from the relevant (package dispatcher type perl5_compat(stash) ) object, but how? sub AUTOLOAD($_ = $CALLER::$_, [EMAIL PROTECTED]) { ... } In a way, $_ forms part of the prototype definition, but is out of band to the regular arguments on @_; it can't interfere with positional characteristics, or you have to shift it off before you goto the right sub. OK, we could play tricks with localization of variables, but in the face of continuations and coroutines, localization falls apart. This is fine for people writing `ordinary code (perhaps), but for a core language feature it should be resolved IMHO. Out-of-band arguments seem to have been a hot topic in the past; http://xrl.us/ggt7 - Long (50+ posts) thread http://xrl.us/ggua - suggestion from Damian; $foo = sub { print $_ } is given($_); I actually quite like that syntax, or at least the idea of using a trait of some kind to specify non-positional arguments. It keeps them well out of the way of `safe programming conventions :). In fact, it has to do wierder things than just accept it out of band to parameters - ideally it would not also interfere with another sub that uses $CALLER::_. Perhaps to avoid that mess, the AUTOLOAD function is simply expected to call func.goto if it wants all the effects of the presence of the AUTOLOAD sub to go away. Assuming that the prototype is re-checked on a goto, to ensure that type guarantees specified in the function signature are honoured, then the necessary side effects should just happen. Sam.