Virtual extension methods -- a strawman design
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)
<T,U> List<T> eagerMap(List<T> list, U(T) lambda)
More information about the lambda-dev