On 6/17/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 16, 2005 at 05:18:51PM -0400, John Siracusa wrote:
> : Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't
> : want to lose the abilities described above.  How would those examples look
> : in "native" Perl 6 code?  (i.e., Without forcing all methods to have a
> : single slurpy [EMAIL PROTECTED] argument, emulating the Perl 5 mechanisms.)
> 
> Something like:
> 
>     # Do something then proceed with call "as usual"
>     method foo ([EMAIL PROTECTED])
>     {
>       ./do_something_new(123, 'abc');
>       ./SUPER::foo(@args);
>     }

Hm, but will that still catch cases where I call foo() with incorrect
arguments?  I like the idea of method signatures that help catch incorrect
calls, but I don't quite understand how I can be ignorant of the "super"
method's signature while (essentially) delegating to it after doing my
thing.  Looking at the above, I wonder if my overridden foo() would
basically remove the benefit signatures, allowing me to call it any which
way.  (Whereas the superclass foo() might have a really strict signature and
catch any bad calls.)

(BTW, I'm not sure where those "./" thingies came from, but it's what GMail
showed in your message.  I'm assuming it should just be ".")

> But you probably want to avoid "super" semantics and write that:
> 
>     method foo ()
>     {
>       ./do_something_else(val => %_<xyz>);
>       next;
>     }
> 
> I've also taken the liberty of deleting your delete, on the assumption
> that your "next" method might want to see the same argument and do
> something else with it.  A set of "next" methods need a consistent
> parameter namespace in any event, so there's no harm in leaving the
> parameter in %_, and some performance benefit in not doing something
> better performed by GC (we hope).

What do you mean by "a consistent parameter namespace"?  Surely they don't
need to have the same signature(?)  That's kind of the point of my second
example: to override a method, add stuff to the signature, act on the new
params, and then delegate the rest to the superclass, calling it as if the
subclass's added params were never there.  That's why I deleted the param
from the hash in the Perl 5 example.

In Perl 6, I'd expect the superclass to puke at runtime if I try to pass it
a parameter that's not in its signature.  I thought you had to explicitly
slurp up "any other args" in your signatures, but I guess I misremembered.

Anyway, I guess I'm just trying to have my cake and eat it too.  I want Perl
5's ability to transparently pass "any remaining/all args" to a superclass
without having to know what kind of args the superclass expects, but I
*also* want to get all of the benefits of strict method signature checking,
even in my subclass method.  So...

    class MySubClass; # a subclass of MyClass

    method foo(<MyClass::foo's signature>, <custom args, if any>)
    {
      # do stuff with custom args, removing them when done
      # call MyClass::foo with the remaining args
    }

...all without ever knowing or caring what MyClass::foo's signature actually
is, of course.  Maybe I'm asking for too much?  (Or maybe I just have to
wait for Damian to come up with some clever technique to do it... ;)

-John


Reply via email to