Coin "reloaded" for lambda ?

[Serge Boulay]

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