RE: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-like with or express
-Original Message-
From: Bart Lateur [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 23, 2000 7:00 PM
To: [EMAIL PROTECTED]
Subject: Re: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-like
"with" or "express"
On Tue, 22 Aug 2000 00:03:48 -0600 (MDT), Nathan Torkington wrote:
Normally what you'd say is:
with (%record) {
}
(look at me, using Larry's new ... operator :-)
No you didn't. You typed four dots.
--
Bart.
Hmmm
... . ...;
or maybe:
while (... .. ...) {
q(can't touch this!)
}
-Corwin
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)
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)
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.
