Auto inferred static imports

[Olexandr Demura]

Having special marker, e.g. `@`, with meaning "inferred type of this place"
will not hurt the readability,
but improve it - `setColor(Color.BLUE)` have some semantical noise
comparing to `setColor(@.BLUE)`.
That could be a nice JEP; and have noting to do with lambdas.
That doesn't help in  Stephen Colebourne's original question with inferring
static helper methods either.
Unless helper methods are defined not is helper class but in target class
itself, causing clutter.

2013/2/7 Ricky Clarkson <ricky.clarkson at gmail.com>

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