> "Nathan" == Nathan Wiger <[EMAIL PROTECTED]> writes:
Nathan> Then we can write really flexible code that looks just like my
Nathan> "religion" wants it to!
Nathan>checktosee [ $NEED eq 'HASH' ] /*
Nathan> var )name assign )DEFAULT ORNEXT
Nathan> $IAMALIVE-member-getName
> 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 C.
Then you get to choose your access mechanism (lexica
>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.
What about
sub somename : method (@args) {
...
On Mon, Aug 28, 2000 at 01:32:49PM -0700, Nathan Wiger wrote:
> 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*!!!
I'll just wait for Rule #1 to be exercised, personally
Damian Conway wrote:
>
> I wouldn't be averse to C as the default and C as a sop to
> the Cerites and C<$ME>ophiles. 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', && =
On 8/28/00 3:53 PM, Damian Conway wrote:
>> Too much B&D for a Monday?
>
> No. I *do* have sympathy with the desire for One True Way, but *only* if the
> access function is called C (my own religion ;-).
>
> And *that's* the problem.
Yeah, there'll never be consensus on this list or in the comm
> 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
On 8/28/00 3:35 PM, Damian Conway wrote:
>> ...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 overhea
> > 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 optimize
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.
>
> 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 arbitr
> > (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
> (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 ma
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]";
>
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 o
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
> >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 hav
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 t
>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
> "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
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
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 demo
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
>sub do_stuff {
>my $self = self;
>$self->{STATE}->{something} = @_;
>}
>
>sub error {
>carp @_ if self->config('VerboseErrors');
>}
I've never really seen anything like this before in other languages (Is that
good or bad?). The closest is Java's odd use o
>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,
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
> =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 Object
27 matches
Mail list logo
