What is the meaning of this?

[Joshua Bloch]

Osvaldo,

On Wed, Feb 3, 2010 at 5:57 AM, Osvaldo Doederlein <opinali at gmail.com>wrote:

> 2010/2/2 Joshua Bloch <jjb at google.com>
>
> Osvaldo,
>>
>> Of course we all believe that we should "design functions [lambdas] as
>> well as we can."  But we disagree about what constitutes quality. I'm deeply
>> concerned about consistency with existing constructs, and conceptual surface
>> area. Java currently has two main  families of types: primitives and object
>> reference types. Object reference types are further subdivided into
>> interface types and class types. Arrays are class types. When we added enums
>> and annotations, they fit conveniently into class types and interface types
>> (respectively). As we add function types and expressions for producing
>> instances of these types (lambdas), we should try as hard as we can to make
>> them fit into the existing type framework of the language.
>>
>
> I agree, these principles are not even debatable - we need to fit new pegs
> in existing holes, as neatly as possible. A perfect fit is seldom possible
> when the core language is not really extensible. Even for something as
> simple as enums, Java5's solution had important tradeoffs (no compatibility
> for the enormous legacy of sets-of-int-constants used as enums; no switch()
> over enums except in the enum class).
>

A minor point, but you can switch over enums wherever you like. In my view,
it's rarely correct to do it *inside *the enum.  But even this is debatable.
 See Effective Java, Pages 154-157 for my take on all this.

>
> The debate happens where there are many possible ways to obtain the desired
> consistency, because there are many existing constructs and concepts to be
> consistent with and you often ought to pick priorities. A function type
> should certainly be a reference type, but... should they have some standard
> root type (like Enum and Annotation)? Should lambda conversion support any
> SAM type, or just SAM interfaces? Should every lambda expression produce an
> object with unique identity? Could a lambda be a simple MethodHandle,
> without any wrapper around that when not necessary?
>
> To summarize my POV, I think the lambda concept should not be tied to its
> implementation (whatever code that javac produces),
>
You'll get no argument there.  We're discussing the desirable semantics, not
implementation.


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


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


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

           Josh