> I think such modules are a bad idea, because their functionality is
> typically restricted.
What, you mean like CGI.pm ?! :-)
> This is a benefit? Forcing multiple authors to use the same 'this' or
> 'self' name across modules is not the perl way
Well, from this logically follows that "forcing" people to use the same
@ARGV or chomp() is not the Perl way, which it obviously is.
This is not "forcing religion", it's Choosing An Interface. It is for
the greater good if we select one way. It changes textbooks to:
"To get the invocant, simply call self()"
From:
"The invocant is in whatever you 'use invocant' with, either a
variable
or subroutine name. By default, it's in $_[0], but this can be named
whatever you want; for the purposes of our examples we'll use $ME."
Perl is tricky enough already; we don't need even more special cases
when some simple compromise will suffice (see my P.S.).
> Migration is as easy with Damian's proposal.
That was actually my point, but just to do things in reverse: by default
have it in self() (or whatever) and allow the person to *revert* to Perl
5 behavior if they want.
To get off the religion point for a second, one thing that hasn't been
discussed but which I've been pondering heavily is the ability to
backtrace contexts like caller(). Consider how this could be used to go
up levels of chained object calls:
Apache->request->uri;
caller(1) caller(0)
self(1) self(0)
That is, self(0) (or just "self") would give you a reference pointing to
the object produced by Apache->request, whereas self(1) would give you a
reference to the original Apache class.
Consider how useful this would be in chained fileobject calls:
open("</etc/motd")->dup->readline;
self(1) self(0)
Here, self(0) would give you a reference to the dup'ed filehandle, and
self(1) would give you a reference to the original one.
This seems very useful to me, and can't be done without a function.
Comments welcome.
-Nate
P.S. And speaking of compromise, I don't think anyone is set in stone on
the name self(). If we decide this(), context(), me(), or some other
name is better, I'm fine with that. But I'm fairly certain that we need
a function given that it has to take arguments. ;-)
