> Mailing List: [EMAIL PROTECTED]
Just to nitpick, this should probably be perl6-language-objects
> sub method ($self, @args) {
> ...
> }
>
> and this may, indeed, be sufficient.
Remember, this still won't solve the problem of a module whose functions
can handle both OO and function-oriented calls - and yes, I have many
that do this. :-)
> use invocant '$ME';
As I've creatively ranted before:
http://www.mail-archive.com/perl6-language-objects@perl.org/msg00131.html
I don't think this is a good idea. But let me explain why, because this
RFC actually handles two different things:
1. Keeping invocant in $_[0] - I think this is a good idea,
but not by default.
2. Allowing access to invocant via special method/var - Again,
good idea, but naming should not be left up for grabs.
Here's the position I'm taking, and I would be surprised if many people
disagreed after reading this short little "speech".
Perl is already widely criticized for having a willy-nilly syntax. This
RFC doesn't help that, it adds more special cases and more ways to do
things which don't add value. Sure, getting to name my invocant $ME
instead of having to use self() or $THIS might give me a warm fuzzy
feeling, but is this important enough to sacrifice the readability and
maintainability of code? Imagine having something else so widely used -
let's say @ARGV - renameable:
use arguments '@CMD';
Now, 300 lines later, you read this:
for $item (@CMD) {
if (grep /$item/, @ARGV) {
push @argv, $item;
}
}
What's @CMD? Oh yeah, it's the command line arguments. But what's @ARGV
then? Silly, that's just a variable that they're using, it has no
relation to other @ARGV's you might see around.
Now, let's imagine our "use invocant" pragma in a similar situation.
package Class::Child;
use invocant '$THIS';
# many many lines pass
sub method {
$savevals = self();
$THIS->pass_values(@_);
return $ME->this($savevals);
}
This might seem contrived, but consider this: the only hope you now have
of understanding this code is forcing yourself to remember that $THIS is
the invocant in this particular module, even though the parent might
use:
package Class;
use invocant 'self';
# many many lines pass
sub method {
$savevals = self();
$THIS->pass_values(@_);
return $ME->this($savevals);
}
Good luck figuring out what's going on here.
Instead, I believe a more sensible approach is the following:
1. By default, pass the invocant via a special var or sub,
either self(), this(), $ME, $THIS, $SELF, or whatever.
2. Allow this to be reverted to the old Perl 5 way ($_[0)
via the "use invocant" (or some similar) pragma.
This gives you the following benefits:
1. Code is consistent. You can be assured that whatever the
function or variable is named is the same across code.
2. Perl 5 to Perl 6 transition is easy - just insert a
"use invocant" at the top of the code and it's passed
in $_[0] just like it always has been.
3. Regardless of passing it in $_[0], it can always be
passed via self() or $THIS still.
Before you balk at #1 in favor of religious flexibility, please consider
how unmaintainable Perl code would be if @ARGV, or $AUTOLOAD, or STDERR,
or @INC, or chomp(), or split(), or any other widely-used variable or
function was renameable. If you don't shudder at this, I would argue you
probably don't maintain enough of others' code.
-Nate
