Removal of function types
Pavel Minaev
int19h at gmail.com
Thu Jul 8 11:28:59 PDT 2010
On Thu, Jul 8, 2010 at 11:20 AM, Rémi Forax <forax at univ-mlv.fr> wrote:
> Java developers are perhaps comfortable with SAMs but
> the main drawback is that there is lot of SAMs that represent
> exactly same thing just because you have to give it a name.
>
> By example, you can count the number of filter/predicate SAM
> you have in the JDK:
> javax.swing.RowFilter,
> java.nio.file.DirectoryStream.Filter,
> javax.lang.model.util.ElementFilter,
> javax.stream.EventFilter,
> java.io.FileFilter,
> javax.swing.filechooser.FileFilter,
> javax.swing.filechooser.FileNameExtensionFilter,
> java.io.FilenameFilter,
> java.util.logging.Filter,
> javax.imageio.spi.ServiceRegistryFilter,
> javax.xml.stream.StreamFilter,
> javax.sql.rowset.Predicate.
This situation is similar to that in C#, which also has nominal
function types only, and there was a proliferation of identical types
throughout the class library. The pragmatical solution to this was to
provide a set of generic types such as Func<...> - a pure library
solution, very easy to implement, and yet it was surprisingly
effective for all the inelegance.
Java doesn't get off the hook that easy because its generics don't
play well with primitives; but then the set of primitives is
non-extensible. So, even though you need many more definitions to
cover all (or even reasonable - e.g. no short, just int/long) ground,
it's a work that can be done once, with code automatically generated
for as many arguments as deemed reasonable, and placed into the
standard library for everyone to reuse.
Yes, it's even less elegant than the .NET solution, but it's still a
workable one, and doesn't require any changes from the language aside
from those already in the proposal. So perhaps it's just good enough?
More information about the lambda-dev
mailing list