Auto inferred static imports

[Ricky Clarkson]

You can already get something very close to that with static imports.  It
would add a small amount of overhead to the compiler.  It would add the
following possible surprise:

Color BLUE = RED;
methodAcceptingColor(BLUE); will that be blue or red?  Either way you will
surprise some users sometimes.  Calling toString() within anonymous classes
is a similar example in current Java in terms of the surprise.

It also negatively affects being able to read code, as you'll have a 'naked
identifier', nothing in the file refers to it apart from your one call,
which increases the dependence on IDEs, makes it harder to read diffs with
or without an IDE, understand online code samples, etc.  Inheritance and *
imports are similar examples from current Java in terms of readability.


On Thu, Feb 7, 2013 at 4:46 PM, Pablo Grisafi <pablogrisafi1975 at gmail.com>wrote:

> I always thought about something like that for enums ...automatic
> import for enums only in method calls.
> if I have enum Color{ BLUE, RED}
> and a method void paint(Color color) in any class
> I think it would be nice to make calls
> paint(BLUE) instead of paint(Color.BLUE)
> compiler can infer the "Color." part, and user can read the code in a
> more natural way...sometimes.
> I like it because it does not pollute the namespace...but I don't
> think we will see that anytime.
>
> >
> > ---------- Forwarded message ----------
> > From: Stephen Colebourne <scolebourne at joda.org>
> > To: lambda-dev <lambda-dev at openjdk.java.net>
> > Cc:
> > Date: Thu, 7 Feb 2013 00:52:02 +0000
> > Subject: Auto inferred static imports
> > I know this is too late, and its probably already been considered, but
> > I haven't seen it mentioned anywhere. And it might trigger a
> > thought...
> >
> > Project Lambda appears to be defining a lot of helper static methods
> > to go with the Stream API. Such as the Collectors class
> >
> >
> http://download.java.net/lambda/b76/docs/api/java/util/stream/Collectors.html
> >
> > I'm assuming that the plan is to remove the static utility class and
> > move the methods to the Collector interface (once the verifier is
> > fixed).
> >
> > The use of code like this results in a need for lots of
> > interface-qualified prefixing, or static imports
> >
> >  someStreamThing.collect( Collectors.groupingBy(...) )
> >  someStreamThing.collect( groupingBy(...) )   // using a static import
> >
> > We also have a similar design pattern in JSR-310 on TemporalAdjuster
> > and TemporalQuery.
> >
> > <maybe-nice-to-have-language-feature>
> > It seems that "it would be nice" if the language could do this for us.
> > Specifically, any static method on a functional interface (or maybe
> > only @FunctionalInterface) is available for use at any call site that
> > is target typed to that interface without any need for an explicit
> > static import.
> >
> >  someStreamThing.collect( groupingBy(...) )   // no need for a static
> > import
> >
> > (no static import needed, because the method collect(Collector) takes
> > a Collector, and the static method is on Collector.
> >
> > Of course an IDE can eliminate much of this pain anyway, so maybe its
> > no big deal and not worth a language chaneg. But it does seem like a
> > potentially useful extension to lambdas/Java. And perhaps it might
> > stimulate another related idea. Since its too late for JDK 1.8, the
> > only point I can suggest is a brief check to see if some other
> > decision has made this an impossible feature.
> > </maybe-nice-to-have-language-feature>
> >
> > Stephen
> >
> >
>
>