On 6/16/05, Gaal Yahas <[EMAIL PROTECTED]> 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...


Reply via email to