"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
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
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
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]";
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
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
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
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
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
(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
(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.
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
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
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
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
=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
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
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
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
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
"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
21 matches
Mail list logo
