Preparing for the 0.2 draft

[Joshua Bloch]

Alex,

Thanks for your continued work on this, and for soliciting our input at this
phase.  I'm heading off for a weekend vacation, and will get back to you on
Monday. I think it would be useful to solicit input from other interested
parties as well, given the self-selected nature of this group.  Very
briefly:

 The "foo.()" invocation syntax looks like a winner,


Agreed.


> and I am seriously considering
> rearranging the function type syntax to have argument types first.
>

This seems iffy.  It is very much at odds with the way things look today.  I
think you'd have a better chance of making a facility that achieved
widespread use by the working programmer if you didn't do this.



> Requiring a lambda expression to denote its return type is also
> increasingly appealing. SAM classes are staying for now.
>

My natural inclination would be to permit but not require this.  If the
compiler can guess the type, great!  If not, help the compiler.  Just like
type inference for generic method invocations.



>
> The discussion of transparent 'this' v. non-transparent 'this' comes
> down to the question of what a lambda in Java is for.


True, but I haven't heard *any *arguments in favor of the "transparent this"
that are in any way applicable to Java. Maybe I'm being dense, but I believe
it's cargo cult language design.  In Java, I believe it would be a
gratuitous inconsistency, pure and simple.  And I believe it would bite us
sooner rather than later.  If I'm wrong, I'd love to see some compelling,
practical examples where having this refer to the enclosing instance is
useful (in Java).


       More next week,

       Josh