Nathan Wiger wrote:
> >
> > 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. :-)
I think such modules are a bad idea, because their functionality is
typically restricted. Altering the language to make that easier seems a
bad idea to me.
>
> 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.
This is a benefit? Forcing multiple authors to use the same 'this' or
'self' name across modules is not the perl way, and it won't help you
unless we also demand naming conventions for methods, classes,
variables, parameters, etc. And then you end up with Java.
>
> 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.
Migration is as easy with Damian's proposal.
>
> 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.
That's not a valid argument. Perl already has multiple different names
for the 'this' or 'self' variable in object methods, and that has not
been a problem so far. If you go to the trouble of studying somebody
another programmer's object module, picking up whether she uses $ME,
self, or this will take a few seconds at most. Understanding the rest of
the module will take far longer...
As for maintaining other people's code, I do that a lot - and,
typically, indentation, comments and brace style cause me far more
trouble than variable names.
Hildo
