Virtual extension methods -- a strawman design

Rémi Forax forax at univ-mlv.fr
Mon May 17 03:09:21 PDT 2010


Le 15/05/2010 19:48, Neal Gafter a écrit :
> On Sat, May 15, 2010 at 10:23 AM, Rémi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     forEach or map or filter are so common that I don't see why
>     they will not be added to the JDK.
>
>
> I can think of many reasons.  Here's one: there is a major design 
> decision about these kinds of methods that has been unexplored.  That 
> is: are high-order functions supplied with the JDK (such as 
> map/filter) lazy or eager?  This decision has an enormous impact on 
> the shape of the ecosystem surrounding the APIs, and is not to be 
> taken lightly.  Making them different on related APIs (e.g. making 
> them lazy on java.util.Iterable but eager on java.util.List) would be 
> a likely disaster, but as far as I know there has been little if any 
> consideration of the impact of this design fork.  This decision also 
> has a large impact on the possible evolution of these APIs and their 
> use in concurrent contexts.

In some use-cases, you want the lazy version and in some others you want 
the eager one,
so I think there is no design decision because you have to provide both.

I propose that by default:
   method on Collection and Map are eager.
   method on Iterator are lazy.

and in java.util.Collections you have both versions:
<T,U> List<T> lazyMap(List<T> list, U(T) lambda)
and
<T,U> List<T> eagerMap(List<T> list, U(T) lambda)

Rémi


More information about the lambda-dev mailing list