Primitives in Generics (+ the meaning of this)

[Alessio Stalla]

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