Primitives in Generics (+ the meaning of this)

[Rémi Forax]

Le 17/07/2010 10:31, Alessio Stalla a écrit :
> On Sat, Jul 17, 2010 at 5:02 AM, Collin Fagan<collin.fagan at gmail.com>  wrote:
>    
>> There were many discussions previously about what 'this' should refer to.
>> Many times the lambdas/closures/whatever were based on interfaces or
>> function types. If I'm understanding things correctly it is now a goal to
>> allow abstract classes which have a SAM to be expressed as a lambda. If this
>> is the case then I would think changing what 'this' refers to is a bad idea.
>> A SAM interface expressed as lambda shouldn't (can't?) contain state on it's
>> own. In these use cases making 'this' refer to the lambda doesn't make a lot
>> of sense. If you want access to *any *state you need to go to the enclosing
>> scope to get it. This direction brought people to MethodHandel as a way of
>> implementing a lambda and the idea that lambdas are *not* objects. While
>> it's possible to have a SAM abstract class that does not have state, I would
>> not put money on it being the most common case. SAM abstract classes really
>> *are *objects. I'm not sure there is a way around that one. If it is an
>> object then we have to worry about identity, equality, new (implicit new?)
>> and all the other things that go along with being an object. Unfortunately
>> that also probably includes the meaning of 'this'.
>>
>> This brings me back to what I consider the fundamental divide among the
>> participants on this list. Hopefully I've understood enough of the messages
>> here to separate the argument into two groups.
>>
>> Group 1 prefers:
>>
>> function types
>> lexical scoping
>> exception transparency
>> lexical break, return, continue
>> MethodHandle
>> and most importantly lambdas are *not* objects
>>
>> Group 2 prefers:
>>
>> interface SAM conversion
>> abstract class SAM conversion
>> local return, break, continue
>> 'this' refers to lambda
>> identity is preserved
>> Method,Constructor and Field references.
>> more like anonymous inner classes
>> lambdas *are* objects
>>
>> There is a word in java for types that aren't objects, primitives. I believe
>> group 1 wants *lambda primitives* and group 2 wants* *(or is willing to
>> tolerate)* lambda objects*. I'm not going to list who belongs to what group
>> but you know who you are. From the proposals so far I get the feeling that
>> the current Oracle work is focused more in the *lambda object* direction.
>> There could be some middle ground but obviously we haven't found it yet. Can
>> we have both? Is there a syntax for *lambda objects* that will leave the
>> door open later for* lambda primitives*?
>>      
> I wouldn't make this kind of distinction. Java already has too many
> primitive types :)
> Function types can still be objects (as in extends java.lang.Object).
> And function types do not imply transparency. In fact my ideal middle
> ground would be:
>
> function types
> lexical closures (full capture of local variables, lifting the 'final'
> restriction)
> interface SAM conversion
> abstract class SAM conversion
> local return (local break and continue make no sense, better to say no
> long break/continue)
>
> i.e. functions exist as first-class objects of a given type, but some
> magic makes them convertible to SAM types. In this scenario it makes
> no sense for this to refer to the function (except maybe for
> self-recursion) because SAM conversion only happens some time after
> the function is created. The compiler can optimize the conversion away
> and directly create the SAM type when it can, but this is just a
> possible optimization.
>
> Alessio
>
>    

+1

Rémi