New

[Howard Lovatt]

In Java there are value semantics for primitives and reference semantics for
Objects, I can't see how you can give lambdas value semantics and therefore
I am proposing reference semantics. What you are proposing is some where in
between the two, where it may be cached and effectively have value semantics
or it may not, in which case you get reference semantics. In particular you
are proposing that ==, !=, equals, and hashCode are effectively undefined
for lambdas. I am far from convinced that this is a good idea, suppose I
want a Set of lambdas!

PS I didn't really get your comment about the GUI example. In particular the
time of creation bit that you mentioned didn't seem relevant (other than to
the particular GUI example). It was an example where object identity was
important - i.e. like a Set as mentioned above. The purpose of the example
was just to illustrate something that a Java programmer might reasonably
expect to work and therefore should be supported (not that there aren't
other ways of coding the problem).

On 30 March 2010 03:14, Neal Gafter <neal at gafter.com> wrote:

> On Mon, Mar 29, 2010 at 5:36 AM, Howard Lovatt <howard.lovatt at gmail.com>wrote:
>
>> A number of people have commented about using new for lambdas, there are
>> at
>> least 4 good reasons to use new:
>>
>> 1. It is what the rest of Java uses, e.g.:
>>
>>  List<Integer> list = new ArrayList<Integer>();
>>  #<int()> lambda = new #<int()>(42);
>>
>
> Only for object creation.  A lambda expression is not a mechanism for
> creating an object, so being consistent in this area would be a
> disadvantage.
>
>
>> 2. It is compatible with the diamond operator from Coin (assuming <> are
>> used), e.g.:
>>
>>  List<Integer> list = new ArrayList<>();
>>  #<int()> lambda = new #<>(42);
>>
>
> Given that they have nothing whatsoever to do with each other, that's a
> disadvantage too.
>
>
>> 3. The main argument for not using new is that the compiler can 'lift' the
>> lambda to be static if it doesn't access any instance fields or local
>> variables. However this type of optimization has a poor history in
>> Java,...
>>
>
> This isn't an optimization.  The compiler needs to translate each lambda
> expression into a reference to a suitable object, and select an appropriate
> lifetime for that object.  The compiler should not intentionally generate
> bad code in the hope that it will be improved later.
>
> ... Note how control over creation is critical, multiple frameClicked()
>> calls
>>
>> can be safely eliminated but multiple fileMenuClicked() calls cannot
>> because
>> these toggle the menu.
>>
>
> Actually, in your example control over creation (of the function object) is
> not at all critical, because the creation time is not visible to the
> program.  I agree that multiple fileMenuClicked() calls cannot be
> eliminated; that is because it has a side-effect "jobs.put(toggleFileMenu);"
> having nothing at all to do with lambda creation.  The (hidden) creation
> time of the function object designated by the lambda has no impact on the
> program's semantics.
>



-- 
 -- Howard.