RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

[Damian Conway]

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)

[Dave Rolsky]

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)

[Michael Maraist]

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 of the super function as the
first line of a constructor.

The first problem I see with this is in [my understanding of] how perl
handles objects currently.

func class csv;
is the same as
class-func( csv )
Which internally becomes a lookup for the proper func based on @ISA, but
ultimatly class gets unshifted onto the stack of parameters.
The only way I can see an easy way of hiding the passage of $self is by
offsetting @_ by one, making $_[ -1 ] = $self.  Which is obviously
unaddressible.  Self would simply make the internal c array-lookup to
[ -1 ].  Either this sort of space would always have to be available, or the
function itself would have to be flagged for it... As in:

sub do_stuff: method {
  my $this = self;  # I'm old fashioned, leave me alone
} # end do_stuff

All accesses to methods would then require the method function-attribute.
Otherwise self could just be an alias for shift.  In this way, you maintain
compatibility (except for those poor souls that currently use method,
locked)

-Michael

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

[Bart Lateur]

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.