On 6/16/05, Gaal Yahas <gaal@[...].org>  wrote:
>  Say I have a class method in FooClass, callable as FooClass.greet():
>  
>       method greet(Class $class: ) {
>          say "Hello, FooClass!";
>       }

Aside from the fact that I don't think this is the right way to
specify class methods...

>  AFAIK, this is the only signature that would work for making &greet a
>  class method; but note that I'm not using $class, and I'd expect the
>  compiler to issue a warning in such a case.

I don't think that the compiler should issue a warning in the case of
unused parameters.  Since the names of parameters mean something more
than just how the method refers to them--they specify the names of
named parameters--it could be useful to accept a parameter that is not
used, in anticipation of them eventually being used.  The "unused
parameter" warning has never caught an error that "undeclared
variable" hasn't for me (as long as I name things well), and usually
is just a cue to bring out my UNUSED fingers.

>  The same problem exists with methods in classes fulfilling a role,
>  but which want to ignore a parameter in a required method.
>  
>  What do you say about this proposed syntax?
>  
>       method greet(Class undef: ) { ... }

Or we could finally take an idea from C++, one that I don't think is
so unreasonable:

    method greet(Class:) {...}

Since there is no :: on the front of Class, it can't be mistaken for a
parameter.  That does bring up the question of what happens if you
want to specify an indirect type as the type of a parameter.  Maybe we
just disallow that...

Luke