>   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:


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();
       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

    package Class;

    use invocant 'self';
    # many many lines pass

    sub method {
       $savevals = self();
       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.


Reply via email to