Problem with method references

[Peter Levart]

On 01/14/11, Stephen Colebourne wrote:
> On 14 January 2011 09:58, Peter Levart <peter.levart at marand.si> wrote:
> > I don't know if we should allways reject #methodName in static context. Only if it refers to instance method. If it refers to static method, it should be a shourtcut for:
> >
> > ClassName#methodName
> >
> > analogous to static method invocation.
> 
> I would say that references to a static method should require the
> class name. Its clearer that way.
> 
> There is a separate, and long-standing, request to add a syntax
> element to refer to the current class. This is often needed in things
> like logging declarations:
> 
>   private static final Logger LOG = LoggerFactory.getLogger(thisclass);
> 
> If that gets added (coin 2?) then it could be used in lambda:
> 
>   thisclass#methodName
> 
> (obviously thisclass is unlikely to be a new keyword, I use it for
> example purposes)
> 
> Stephen

In your logging example, thiscalss seems to refer to a java.lang.Class object instance (at least that's what is expected as a parameter in the getLogger method). Did you mean to write thisclass.class instead?

In your method reference example thisclass is a substitute for the class name of the class that is the immediate lexically enclosing class (and is valid in instance as well as in static contexts).

But as we often call static methods from within static contexts without specifying their declaring classes (or subclasses) we might as well support referencing those methods in analogous way. This would go as far as supporting static imports too.

If we follow method/constructor invocation syntax as closely as possible, existing Java developers would grasp the syntax more quickly.

The only conceptual addition to method/constructor invocation syntax is prefixing instance method / inner class constructor with declaring / enclosing class name:

  DeclaringClassName#instanceMethod

  EnclosingClassName#new InnerClass;

... to construct a function that takes an additional 1st argument being an instance of declaring/enclosing class. These two forms have no analogous counterparts as method/constructor invocations so their syntax does not associate to any known concept.
 
Peter