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...
Luke
