What is the meaning of this?

[Osvaldo Doederlein]

Joshua,

2010/2/3 Joshua Bloch <jjb at google.com>

> Osvaldo,
>
>> and it should not be tied to the needs of SAM types (this is strictly a
>> backwards-compatibility feature: the tail shall not wag the dog;
>>
> I'm not so sure about this.  SAM *interface *types are a good thing!
> Unlike function types, they have names (e.g. Reducer), semantic constraints
> (e.g., Must be associative), they provide the opportunity for type-specific
> documentation (e.g., A specialized combiner that accepts to instaces of some
> type and returns an instance of the same type). SAM interfaces provide great
> advantages when used with IDEs (autocompletion, context-sensitive
> documentation, etc.).  So I think we all agree that it's critical that the
> solution works beautifully with SAM *interfaces*. SAM *classes *are
> perhaps less critical, though even they will have non-legacy uses.  There
> are several valid reasons to use a SAM class instead of an interface.  One
> is performance (e.g., TimerTask). Another is Instance control (with a class,
> you can write the sole constructor, and keep track of every instance). But I
> would be willing to sacrifice good support for SAM *classes *if we decide
> that it provides large benefits.
>

Agreed, SAM interfaces are great, considering that we don't have a typedef
construct. We keep wishing for typedefs, they would become even more useful
now (for both generics and lambdas, as already discussed in this list) but
this is a big RFE and not in the viable scope for Java7, so a nice support
for SAM interfaces is really the way to go, even not considering legacy
APIs.

I'm also willing to drop SAM classes, remarkably if they impose
*any*further tradeoff to lambdas at large. ;-) Although SAM classes
are tempting
(usage is not insignificant), it's not bad to favor usage of interfaces in
general - people will often write a SAM class (or an abstract class with a
handful, unrelated abstract methods) when they could have used a SAM
interface (or a handful), perhaps just with the cost of some delegation,
often not even that cost (just laziness to create a pair of interface +
abstract base class).


>
>
>>  Lambdas should not be forced to look like methods-of-objects, complete
>> with a self-referent 'this'.
>>
> This is the fundamental issue of this thread.  I don't see this is being
> forced to do the wrong thing.  I see it as the obvious correct thing. I
> believe we need a strong argument to do otherwise, because doing otherwise
> is an inconsistency. I see the "transparency" argument as weak. I'm not even
> quite sure what people mean by it, and I don't know what it buys me in the
> context of this effort.
>

I think the core argument is discouraging the use to see the lambda as a
method inside an object, and write code that depends on this assumption and
perhaps will depend on implementation details, and make certain
implementation strategies dangerous. Well, we might just force javac's
translation strategy to some standard/"safe" option (synthetic class with
certain visible properties, or MethodHandle if this can be used by arbitrary
lambdas), for lambdas that use 'this' (and also, obviously lambdas that are
assigned to variables or SAM-converted). Avoiding those will become just a
best-practice: if you don't do that, javac and/or HotSpot may generate much
simpler/faster code and perform aggressive optimizations like full inlining
of uses of select control abstractions. If you don't, these opts cannot be
used.


>  Lambdas that must be represented as instances but don't capture enclosing
>> state should not be forced to be unique instances.
>>
> You'll get no argument here! And I don't see this having any bearing on the
> meaning of "this." I see a lambda expression as a sort of a static factory.
>  If you evaluate it ten times, it's fine if all ten evaluations produce the
> same object, in which case I believe that this should return the same value
> in all ten.
>

This agreement makes me very happy. This was subject to debate in some
emails.

A+
Osvaldo