Re: Curious about method handling

> There is another method to achieve this, which other helpful people have 
> suggested:
> 
> class A {
>   String greeting;
>   String greet() = this.greeting;
> }
> 
> new A(String s) {
>   this(greeting: s);
> }
> 
> void printOutput(A klass, A->String func ) {
>   println( func(klass) );
> }
> 
> void main(String[] args) {
>   printOutput( new A("Hello World"), greet );
> }
> 
> This appears neater, but it contains a superfluous type. The compiler doesn't 
> need to know the class of the object the method belongs to. All that should 
> be necessary to know is the input types and output type of the method.

'new A("Hello World")' is not a type, it's an instance of the type.
 From what i see in your Python example, Python ignores the "input 
types" of the method, it generates an anonymous void->String method 
instead. I am not aware of such a syntactic sugar in Nice.

> 
> Given the above example, I can't do this without coming up against a type 
> error:
> 
> class B {
>   String farewell;
>   String bye() = this.farewell;
> }
> 
> new B(String s) {
>   this(farewell: s);
> }
> 
> void main(String[] args) {
>   printOutput( new B("Hello World"), bye );
> }

That is becouse the "input types" of the "bye" method are different: 
method "greet" has "input types" of (A), and method "bye" has "input 
types" of (B), that is, compiler behaves exactly as you've said: it only 
cares about "input types and output type of the method".

> So I wonder if a slight change in syntax would be feasible.
> 
> If "className.methodName" returned the method itself, not the return value of 
> the method, it would make it consistant with the syntax for non-class 
> methods.
> 
> So I could do this:
> printOutput(new A("Hello World").greet)
> 
> This syntax would be particularly useful for lookup tables that refer to 
> multiple classes. e.g:
> [
>   (KeyEvent.VK_LEFT, Spaceship.moveLeft),
>   (KeyEvent.VK_RIGHT, Spaceship.moveRight),
>   (KeyEvent.VK_P, Game.pause)
>   (KeyEvent.VK_ESCAPE, Game.quit)
> ].listToMap();

If the compiler should remember the first argument of a method (which is 
Spaceship or Game instance, in your example), why shouldn't it remember 
other other arguments as well? The syntax should involve other 
arguments, like
   (KeyEvent.VK_LEFT, Spaceship.moveLeft(2)),
   (KeyEvent.VK_RIGHT, Spaceship.moveRight(2)),
   (KeyEvent.VK_P, Game.pause())
   (KeyEvent.VK_ESCAPE, Game.quit(0))
but that is already used for direct method invocation, thus we left with
   (KeyEvent.VK_LEFT, ()=>Spaceship.moveLeft(2)),
   (KeyEvent.VK_RIGHT, ()=>Spaceship.moveRight(2)),
   (KeyEvent.VK_P, ()=>Game.pause())
   (KeyEvent.VK_ESCAPE, ()=>Game.quit(0))

> Is there any reason I don't know about that would make altering the syntax 
> like this this a bad idea? Is there any benefit to having class.method === 
> class.method() ?

I never use the "class.method" syntax personally, don't know if it will 
stay as it is, either.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf