Method calls vs lambda calls

[Howard Lovatt]

Answers inline below

2009/12/15 Neal Gafter <neal at gafter.com>:
> On Tue, Dec 15, 2009 at 7:11 AM, Howard Lovatt <howard.lovatt at iee.org>
> wrote:
>>
>> I remain to be convinced that method references are a good idea, since
>> they pull Java much further towards structural typing than at present
>> and this will be very confusing for people to be presented with two
>> type systems.
>
> I don't know what this argument has to do about method references (are you
> talking about function types?),

Yes, my mistake I meant to say function types

> but your argument makes no sense.  They're a
> good idea because they will confuse people?  Huh?

I think you might have misread what I said, I said "I *remain* to be
convinced ... since ... this will be very confusing". Your confusion
was probably caused by my mistake of saying method references - sorry.

To spell this out I think that *function types* are a bad idea because
they will confuse people. People will be confused because they are
structurally typed, whereas as the rest (well most) of Java is
nominally typed.

>>
>> That desirability point aside, the technical issue of what name space
>> a function type should be in can be resolved by putting a function
>> type in both the method and the field/variable name spaces.
>
> Function types are anonymous, and so don't need to go in any namespace.  Do
> you mean a variable of function type?

Yes, I had assumed that was apparent from the context of the
discussion - that is what the thread is about. This discussion in the
thread is centered on how you get the following to work:

#int() fortyTwo = #int() (42);
out.println( fortyTwo ); // prints something like
Function_intATSomeAddress (I used AT instead of an At symbol because
of pipermail)
out.println( fortyTwo() ); // prints 42

>> Actually there are still some rough edges since methods are
>> dynamically resolved and fields aren't. You can paper over this
>>
>> difference a little by saying that function types can't be hidden.
>
> What do you mean: hiding triggers an error (that would make code very
> fragile, especially where the hidden name isn't even used)?  Or that the
> name isn't hidden?

If you allow function-type variables to be hidden (static case) or
shadowed (instance case) then it can be very confusing, e.g.:

class FortyOne {
  int f() { return 41; }
  #int() ft = #int() (41);
}
class FortyTwo extends FortyOne {
  int f() { return 42; }
  #int() ft = #int() (42);
}
FortyOne aFortyTWO = new FortyTwo();
out.println( aFortyTWO.f() ); // prints 42
out.println( aFortyTWO.ft() ); // prints 41!!!

To prevent the above confusion you could say that function-type
variables cannot be hidden/shadowed then this makes the above example
an error, on the other hand it isn't very Java like. The other options
are:

1. The FCM solution of requiring call, e.g. aFortyTwo.ft.call()
2. Introduce properties and say that function types can only be used
as a property (a much bigger change and odd that function types can
only be a property)
3. Only allow the non-call syntax, e.g. aFortyTWO.ft(), if there is no
method called ft and if ft hasn't been shadowed or hidden by another
field/local (again, not very Java like)
4. Don't allow function types at all - my favorite!

Cheers,

 -- Howard.

>
> Cheers,
> Neal
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
  -- Howard.