Coin "reloaded" for lambda ?

[Brian Goetz]

Mark did indeed post asking for platform feature ideas.  But note that 
there's way more to the Java platform than the Java language -- so 
"language features" are only a subset of "platform features".  With 
Lambda already in the pipe, the "language features" bucket is pretty 
full already (with some of the big-ticket items Mark alluded to.)

On 6/21/2011 11:27 PM, Serge Boulay wrote:
> I thought that other languages features "both large and small" were
> being considered ? Mark Reinhold posted a blog sometime ago asking for
> proposals
> http://mail.openjdk.java.net/pipermail/discuss/2011-March/001704.html .
>
> On Tue, Jun 21, 2011 at 7:27 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     The extent of the Coin contribution to Java SE 8 is not yet determined.
>       However, it is safe to assume that with big changes to the language
>     (lambdas, extension methods), platform (modularity), and libraries
>     (collections upgrades), that the Coin contribution will be smaller than
>     it was in 7.  Likely candidates include collection literals and
>     repeating annotations -- both of which were things that were desired for
>     Coin I but missed the cut.  I think it is safe to assume that Elvis and
>     Properties will not be coming in 8.
>
>     On 6/21/2011 7:17 PM, Artur Biesiadowski wrote:
>      > Hello,
>      >
>      > There was discussion some time ago about how short lambdas will
>     be with
>      > java language in real world. Some examples were given where simple
>      > concepts were being lost because of extra verbosity needed to handle
>      > equality/null safety etc.
>      >
>      > Is there any chance that next incarnation of coin project (one going
>      > together with lambdas for java 8) could incorporate some changes
>     which
>      > would actually allow writing shorted lambads in java?
>      >
>      > I'm talking about elvis operators in particular. While I
>     understand that
>      > they were rejected for 'normal' java usage, I think they could be
>     very
>      > useful in helping with shorter lambda expressions. If we could
>     get a set
>      > of collection operations which would be null aware (and skipping
>     nulls
>      > instead of trying to preserve them), we probably can treat null
>     as poor
>      > man None Option from scala.
>      >
>      > ?: is the same as getOrElse from scala.
>      > ?. would allow some of the collect/foreach/filter operations to be
>      > considerably simpler
>      >
>      > It is still not solving many of the problems - following will not
>     work
>      >
>      > list.filter(x ->  x?.getPerson()?.getAge()>  35)
>      >
>      > list.filter(x ->  x?.getState()?.isEnabled())
>      >
>      > Another missing part is safe equals method call ( x == y ||
>     (x!=null&&
>      > y!= null&&  x.equals(y) ). Can be easily emulated with static
>     import and
>      > eq(x,y), so probably it is not a killer.
>      >
>      > There might be some other possible improvements - my point is
>     that maybe
>      > some previously rejected ideas could be reevaluated from the
>     perspective
>      > of helping short lambdas.
>      >
>      > True property support would also help a lot, but this is for sure
>     out of
>      > scope for now...
>      >
>      > With best regards,
>      > Artur Biesiadowski
>      >
>
>