Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
"Nathan" == Nathan Wiger [EMAIL PROTECTED] writes: Nathan Then we can write really flexible code that looks just like my Nathan "religion" wants it to! Nathanchecktosee [ $NEED eq 'HASH' ] /* Nathan var )name assign )DEFAULT ORNEXT Nathan $IAMALIVE-member-getName++ Nathan perishPolietly "Couldn't get )name" unless )name++ Nathan ilovemymom )name++ Nathan var )user assign )name ORNEXT "user"++ Nathan fork "ls -l" THISTOO perishPolitely "ls failed: $boogeyman"++ Nathan*/ Heh ... flashback to the V7 Bourne shell (the One True Shell) source code, written in Algol, #define'd so that it would compile with C. :) Truly a masterpiece of well-intended-but-poorly-executed famous last words. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
Damian Conway wrote:
I wouldn't be averse to Cself as the default and Cuse invocant as a sop to
the Cthiserites and C$MEophiles. But *they* might be!
This is baloney. I agree, we need to *pick something*!!
What should we do, make a "rename" pragma so everyone can be happy?
use rename want = '$NEED', = 'THISTOO',
self = '$IAMALIVE', || = 'ORNEXT',
chomp = 'Ilovemymom', caller = '$CALLERFORTHIS',
my = 'var', $ = ')', = = 'assign',
- = '-member-', ; = '++', die = 'perishPolitely',
system = 'fork', { = '/*', } = '*/', $! = $boogeyman,
( = '[', ) = ']', if = 'checktosee';
Then we can write really flexible code that looks just like my
"religion" wants it to!
checktosee [ $NEED eq 'HASH' ] /*
var )name assign )DEFAULT ORNEXT
$IAMALIVE-member-getName++
perishPolietly "Couldn't get )name" unless )name++
ilovemymom )name++
var )user assign )name ORNEXT "user"++
fork "ls -l" THISTOO perishPolitely "ls failed: $boogeyman"++
*/
This is, obviously, complete insanity. And a load of shit.
We can pick self(). Or this(). Or me(). Or context(). Or invocant().
Or $ME. Or $SELF. Or $THIS. Or $CONTEXT. Or $INVOCANT.
But we have to f**king pick *something*!!! Someone's going to be unhappy
but:
1. They'll get over it.
2. It's for the greater good.
Anyone who counters and says "but it's crucial that the invocant *must*
be named X" is inflexible and full of shit.
The *only* decent point I've heard so far is that some people might want
$self still as $_[0]. We should accomodate this.
-Nate
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
On Sun, Aug 27, 2000 at 07:54:35PM -0700, Nathan Wiger wrote: And why is passing $self in $_[0] a good thing? Because it eliminates a butt-load of translation to convert Perl5 programs to Perl6 programs. Rather than tracking down each and every sub and figuring out if it's used as a method or not, nothing is changed and things simply work. But the Cself or C$ME functionality is still there for people to use. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
Damian Conway:
My forthcoming proposal will be that invocants still be passed as $_[0]
by default, but that there be a pragma allowing $_[0] to be automagically
shifted somewhere else during dispatch. For example:
sub method { print "I was called through: $_[0]";
print "My args were: @_[1..$#_]"; } #default
use invocant '$ME';
sub method { print "I was called through: $ME";
print "My args were: @_"; }
Why couldn't(/shouldn't/wouldn't) this be more useful as a facility that
allows you to define a chunk of code that gets inserted in each sub routine?
I'm not sure what the general facility would look like, but it seems to me
like the "use invocant 'variable'" pragma is just essentially sticking a:
my variable = shift ;
as the first line in each method... wouldn't it be more fun to let people do
something like:
use invocation 'my $ME = shift; print "I was called through : $ME" ;
print "My args were : @_" ;'
... which, of course, means that duplicating the method above is as simple
as:
sub method { # use invocation stuff gets shoved in here
}
(Or, was it already intended that the implementation of 'use invocant' might
be some sort of compile-time macro?)
Dirk
RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )
What I meant to say was more along the lines of "if this could be done as a macro, does it need to be a pragma, or could it be part of a standard macro package?" And, secondly, "if this *is* part of a standard macro package, wouldn't it be cool to let it shove arbitrary code around rather than just doing invocant access syntax?" Sure. *If* the hypothetical macro package comes to be, this and many other proposals could be subsumed by it. But that's a mighty big "if" :-) Damian
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
On 8/28/00 3:09 PM, Damian Conway wrote: (Or, was it already intended that the implementation of 'use invocant' might be some sort of compile-time macro?) No. I think a macro facility for Perl should be more general than just whacking some code in at the start of every subroutine. The use invocant was proposed as a way to maintain backwards compatibility and yet give everyone the invocant access syntax he or she personally favours. ...while also giving the compiler enough information to allow such invocant access to execute in an optimized manner...right? C'mon, I'm dying here thinking that all this (admittedly cool) stuff is gonna end up giving Perl 6 even more OO overhead than Perl 5! You don't want to have to revise that section of your OO Perl book to include an even *more* daunting performance degradation factor estimate for Perl OO design, do you? :) (What was it in the current edition..."up to 20x slower"? *sigh*) Anyway, I think that the "invocant" proposal is very Perl-ish...in both the best and worst senses of the word. Giving everyone the freedom to $ME and "self" to their hearts' content is TMTOWTDI up the wazoo. I'd probably be happier with a One True "self-thingie" decision...unless, of course, it's one of the ones I personally dislike ;) But I have faith that The Powers That Be would pick something sane like $self before a fanciful $THIS_IS_ME. I'm also a bit concerned about readability and interoperability of "Your Objects" vs. "My Objects." I guess invocant directives are self-documenting and should not cause any problems, functionally. But it still kind of creates a "...so we punted" feeling in me. Again, the dark side of Timmy's Toad... -John
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )
The use invocant was proposed as a way to maintain backwards
compatibility and yet give everyone the invocant access syntax he
or she personally favours.
...while also giving the compiler enough information to allow such
invocant access to execute in an optimized manner...right? C'mon,
I'm dying here thinking that all this (admittedly cool) stuff is
gonna end up giving Perl 6 even more OO overhead than Perl 5!
Use invocant won't add any runtime overhead. In fact it might save a smidgeon.
(What was it in the current edition..."up to 20x slower"? *sigh*)
Out by a factor of 10! I said "20 to 50 percent slower".
I'm also a bit concerned about readability and interoperability of
"Your Objects" vs. "My Objects." I guess invocant directives are
self-documenting and should not cause any problems, functionally.
I think they would *improve* readability. Certainly over $_[0], and
even over:
sub method {
my ($self, @args) = @_;
...
}
I'm *forever* writing that and just it clutters up the code.
Damian
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )
I was talking about the hypothetical situation where you're (re)using or modifying a bunch of code or classes written by different people and you constantly have to be aware of which self-thingie to use in which file or package or whatever. Yeah, you can just glance up to the use ... declaration, but it still seems a little like trying to make everyone happy by avoiding the naming decision entirely. Too much BD for a Monday? No. I *do* have sympathy with the desire for One True Way, but *only* if the access function is called Cself (my own religion ;-). And *that's* the problem. I wouldn't be averse to Cself as the default and Cuse invocant as a sop to the Cthiserites and C$MEophiles. But *they* might be! :-) Damian
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
On 8/28/00 3:53 PM, Damian Conway wrote: Too much BD for a Monday? No. I *do* have sympathy with the desire for One True Way, but *only* if the access function is called Cself (my own religion ;-). And *that's* the problem. Yeah, there'll never be consensus on this list or in the community as a whole, but I think I'd be happy with a small group of people (a group that includes Larry, obviously) just plain picking something in this case. I mean, hey, who got to vote on % for hashes and such? Rewind this list a decade or so and we might see something like: use prefix (hash = '%', array = '@', ...); being proposed because everyone can't agree on punctuation prefixes. Okay, dumb example maybe, but you get the idea. Choose or lose, as the kids say on the MTV. -John
RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )
(Or, was it already intended that the implementation of 'use invocant' might be some sort of compile-time macro?) No. I think a macro facility for Perl should be more general than just whacking some code in at the start of every subroutine. The use invocant was proposed as a way to maintain backwards compatibility and yet give everyone the invocant access syntax he or she personally favours. Damian
RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )
(Or, was it already intended that the implementation of 'use invocant' might be some sort of compile-time macro?) No. I think a macro facility for Perl should be more general than just whacking some code in at the start of every subroutine. Yes. I didn't phrase my comments well. Sorry. The use invocant was proposed as a way to maintain backwards compatibility and yet give everyone the invocant access syntax he or she personally favours. Sure, but isn't this essentially a macro? (If it *isn't*, then I'm missing something... which could very well be the case). What I meant to say was more along the lines of "if this could be done as a macro, does it need to be a pragma, or could it be part of a standard macro package?" And, secondly, "if this *is* part of a standard macro package, wouldn't it be cool to let it shove arbitrary code around rather than just doing invocant access syntax?" Dirk
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )
What about
sub somename : method (@args) {...}
And leaving your$self some other way at the object?
That's the idea. By default you get the invocant in $_[0],
but you can have the compiler extract it for you via Cuse invocant.
Then you get to choose your access mechanism (lexical scalar or subroutine)
and what that access mechanism is called.
And yes, it *would* be great if methods honoured their parameter lists!
:-)
Damian
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
Damian Conway wrote:
My forthcoming proposal will be that invocants still be passed as $_[0]
by default, but that there be a pragma allowing $_[0] to be automagically
shifted somewhere else during dispatch. For example:
use invocant '$ME';
sub method { print "I was called through: $ME";
print "My args were: @_"; }
What don't you like about the current RFC? What specific problems are
there? I would urge you to read through the thread some.
The RFC notes you can call self() anywhere, allowing you to arbitrarily
encapsulate code. I don't see how a pragma could do this.
How is your idea any better than:
sub method {
my $ME = self;
}
And why is passing $self in $_[0] a good thing?
If we're going down the prama path, I say we get rid of want() and
instead have a pragma:
use want '$WANT';
sub method {
if ( $WANT eq 'HASH' ) { ... }
}
This seems just as silly to me. We have caller(), want(), why not
self()?
-Nate
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
Currently, the current object context is passed into a sub as the first
element of @_, leading to the familiar construct:
my $self = shift;
However, this is a big PITA. In particular, if you support lots of
different calling forms (like CGI.pm), you have to check whether $_[0]
is a ref, etc, etc, etc.
It is? I don't see that this is a pain at all. It seems like
a beautiful point of homogenization. You don't force the user
to say $self; they could use $this if they wanted. Heck, they
don't need it at all.
my(undef, @args) = @_;
Or as in
shift-fn(@_)
This is one of the things that Larry, in borrowing much of Perl's
OO from Python, carefully preserved from the parent tongue. Don't
see why you would break it.
My forthcoming proposal will be that invocants still be passed as $_[0]
by default, but that there be a pragma allowing $_[0] to be automagically
shifted somewhere else during dispatch. For example:
sub method { print "I was called through: $_[0]";
print "My args were: @_[1..$#_]"; } #default
use invocant '$ME';
sub method { print "I was called through: $ME";
print "My args were: @_"; }
use invocant '$MYSELF';
sub method { print "I was called through: $MYSELF";
print "My args were: @_"; }
use invocant 'self';
sub method { print "I was called through: ", self;
print "My args were: @_"; }
use invocant 'this';
sub method { print "I was called through: ", this;
print "My args were: @_"; }
use invocant 'the_great_and_powerful_OZ';
sub method { print "I was called through: ", the_great_and_powerful_OZ;
print "My args were: @_"; }
Backwrds compatibility is preserved, everyone's religion is covered, and
the choice is made explicit.
Damian
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
Tom Christiansen wrote: It is? I don't see that this is a pain at all. It seems like a beautiful point of homogenization. You don't force the user to say $self; they could use $this if they wanted. Heck, they don't need it at all. my(undef, @args) = @_; It's a pain if you want to support both function-oriented and object-oriented calling forms, as CGI.pm does. For example, you can use both of these: print header; print $r-header; with CGI.pm. Now you need a self_of_default special method, since sometimes $_[0] has a class ref and sometimes it has the first method argument. Or as in shift-fn(@_) I don't see how this RFC is super-revolutionary, personally. Your example would just become: self-fn(@_); with the added benefit that, unlike shift-fn(@_), you can call the same thing 10 times in a row and it still works: self-fn1(@_); self-fn2(@_); # can't do that with shift I also don't see how this precludes the use of $ME, $self, $this, or any other variable name: $ME = self; $self = self; $this = self; -Nate
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
=head1 TITLE Replace $self in @_ with self() builtin (not $ME) Don't impose your religion on others. If people want 'this' instead of 'self', that should be just fine. It should be pretty easy to define the appropriate $ME-reader like this: use ObjectStyle 'self'; or use ObjectStyle 'Java'; for the appropriate, per-module scoped, definitions for: - self vs this - super vs SUPER vs base vs parent - DESTROY vs finalize vs destructor - default of 'private', 'protected' or 'public' and any others we can come up with... Hildo
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
On Thu, 24 Aug 2000, Hildo Biersma wrote: Don't impose your religion on others. If people want 'this' instead of 'self', that should be just fine. It should be pretty easy to define the appropriate $ME-reader like this: use ObjectStyle 'self'; or use ObjectStyle 'Java'; for the appropriate, per-module scoped, definitions for: - self vs this - super vs SUPER vs base vs parent - DESTROY vs finalize vs destructor - default of 'private', 'protected' or 'public' and any others we can come up with... I'm all for TMTOWTDOI but I really object to this idea. I have enough to deal with when reading other's modules without having to look for DESTROY *or* destroy *or* finalize *or* I_am_dying *or* whatever. Perl needs to walk a line between being flexible and remaining a language where I can download something from CPAN and have some chance of understanding it. Maybe the following would be ok: use self; # otherwise object is in @_ That I could live with. 4 different sets of object names and special sub names would kill me. -dave /*== www.urth.org We await the New Sun ==*/
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
Tom Christiansen wrote: So it seems that what you're saying is that you'd like a way to *know* for certain whether you were invoked as a method -- or not, as the case might be. Sort of. Actually, I want to not care. Adding a :method constraint doesn't help (actually hurts) because then the two styles - object and function oriented - aren't freely interchangeable. Then again, in days of old when porters were bold and objects were just invented, Dean used to preach to us not to be overly concerned about whether the object invocation syntax had been subverted via direct calling of the subroutine. That's what I like about this. self() can be used anywhere, in any context, and it Does The Right Thing (assuming you're not a bozo). Finally, while I may be wrong, I don't really get the idea that this situation seen in CGI.pm in which a sub is sometimes a function called with N arguments and sometimes a method called with N+1 arguments is one which is in the least bit common. In fact, I've even heard argued its (un)desirability in the first place. It's probably not that common. But it is very useful. CGI.pm uses it with great benefits, and File::Remote lets you use an object-oriented style or lets you override the builtin open() et al operators. In these cases and others, being able to choose either interface is very powerful. And self() eliminates the needless leaps and bounds you have to go through for this to work. Plus, don't overlook that self() is not just a replacement for shift in the first line of a sub. :-) It is a full context function, just like want(), ref(), and caller() (thanks Bart). -Nate
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
Hildo Biersma wrote:
=head1 TITLE
Replace $self in @_ with self() builtin (not $ME)
Don't impose your religion on others. If people want 'this' instead of
'self', that should be just fine.
Whoa! I'm not imposing religion on others. FAR FROM IT! Maybe the
examples I demonstrated were too tricky and missed the main point.
Right now, a sub would be written as:
sub mymethod {
my $this_is_my_name = shift;
@args = @_;
}
Under this RFC, you would write it as:
sub mymethod {
my $this_is_my_name = self;
@args = @_;
}
The key difference is this: $_[0] always contains the first method
argument, regardless of whether you're in an object-oriented or
function-oriented context. So, if you need to support both (like CGI.pm
and my own File::Remote must), you don't have to write some special
method that detects whether $_[0] is a valid class ref (see
self_or_default in CGI.pm).
Instead, you know that all the args are always in @_:
sub mymethod {
my $ME = self;
@args = @_;
}
And you can now call this as:
Class-mymethod
Class::mymethod
mymethod
And all will work without having to rewrite your sub.
This fixes a lot of stuff. Plus, "self" is one char shorter than
"shift"! ;-)
-Nate
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
On Thu, 24 Aug 2000 13:27:01 -0700, Nathan Wiger wrote:
It's a pain if you want to support both function-oriented and
object-oriented calling forms, as CGI.pm does. For example, you can use
both of these:
print header;
print $r-header;
with CGI.pm. Now you need a self_of_default special method, since
sometimes $_[0] has a class ref and sometimes it has the first method
argument.
Don' forget to mention that if the sub can also be used as a class
method, the is NO WAY to distinguish between
CGI-header
and
header("CGI")
Hence, with some values for the functional argument, the detection
mechanism is unreliable.
Either $ME or self() (which, BTW, is more related to caller() than to
ref()) is 100% reliable.
--
Bart.
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
"Nathan" == Nathan Wiger [EMAIL PROTECTED] writes: Nathan The key difference is this: $_[0] always contains the first method Nathan argument, regardless of whether you're in an object-oriented or Nathan function-oriented context. So, if you need to support both (like CGI.pm Nathan and my own File::Remote must), you don't have to write some special Nathan method that detects whether $_[0] is a valid class ref (see Nathan self_or_default in CGI.pm). yes, I like this. Nathan This fixes a lot of stuff. Plus, "self" is one char shorter than Nathan "shift"! ;-) Heh! All that typing I would have saved over the years, would probably be equal to the number of characters I've typed here debating this point. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
