Syntax for calling super

[Gregg Wonderly]

On Aug 27, 2012, at 5:41 AM, Peter Levart <peter.levart at marand.si> wrote:

> On Friday, August 24, 2012 11:00:03 AM David Holmes wrote:
>>> Intuitively I don't have problems with K.super. I see K.something as
>>> something qualified with type K.
>>> 
>>> In case of "this" it selects the innermost instance of type K, whereas in
>>> case of "super" it selects the most specific visible member from the
>>> superclass/superinterface K's hierarchy.
>>> 
>>> In both cases K is an addidional restriction to the "search strategy".
>> 
>> K.super.m() already has an existing meaning with inner classes, just as 
>> K.this.m() does. There's a difference between searching for a type alone 
>> and searching for an object and then a type. Using the same notation is 
>> confusing in my view.
> 
> Oh, I wasn't aware of that. That changes things. In particular if there was a 
> situation where it could resolve to both (the super method of an outer 
> instance and the particular super interface's default method). There would 
> have to be a precendence rule or an unresolvable conflict which complicates 
> things further.

There can be no such conflict.  The same "K" can not exist as an interface and a class, in an ambiguous way.  There is a package difference, or an inner class "path" difference that can be enumerated with a qualified name expect ion.

packageA.K vs packageB.K or A.K vs B.K etc.

This is not a "conflict" issue.

> Also the question remains about the syntax of calling the particular 
> superinterface's (K's) default method from an inner class of an Outer class 
> implementing the interface? Outer.K.super() or K.Outer.super() ? Isn't that 
> ambigous too?

Can you specify what you mean by ambiguous?  Is there actually missing information that causes K to not be resolved, or is it just thinking about it causes your thought process to not be clear on what is happening?

> Somewhere in another message you mentioned that K.super.m() in an inner class 
> could be viewed as a shorthand for K.this.super.m(). Now if the later syntax 
> was realy a legal syntax and K.super.m() just a shorthand for it, then:
> 
> super.m()
> 
> would actualy be a shorthand for:
> 
> this.super.m() 
> 
> 
> To select a particular interface's default method you could then cast "this" 
> to it's type:
> 
> ((K) this).super.m();
> 
> 
> Compiler would have to prove that the expression before .super.m() (the 
> receiver) actualy is "this" (could also be an Outer.this) and the type of the 
> expression is one of the "direct" supertypes of the class in context.
> 
> To call  the particular superinterface's (K's) default method from an inner 
> class of an Outer class implementing the interface, you could use:
> 
> ((K) Outer.this).super.m();

I think it's unnecessary to add this much syntax to just say "invoke the interfaces default method".  When you present the compiler with the expressions:

OuterName.this.m();

Whether or not this is in an inner class, the compiler will resolve OuterName to find it's declaration.  If OuterName is an "outer class", then the compiler will resolve the method reference and generate an invocation of it.  That is what happens today.

For default methods, if you coded the same expression:

OuterName.this.m();

The compiler can do the same work to resolve OuterName.  It could next see if the name resolves to an interface, and if there is an "m()" default method provided.  If so, in can generate code to invoke that.

That seems natural, and unambiguous to me.

Gregg