Syntax for calling super

[David Holmes]

Gregg,

The distinction is not OuterName.this versus OuterName.super. Both of 
these exist today in the context of inner-classes - specifically 
accessing members of an enclosing class instance.

The proposal to use K.super.m() for default method access is completely 
different to that usage - there is no other instance involved.

We already have "super" to indicate that we want to look-to/access 
something in a supertype, but super.m() is not expressive enough to 
solve the default method problem, and super.K.m() can be ambiguous (if K 
is also the name of a member of your supertype). So K.super.m() has been 
proposed to address that. As a standalone suggestion it would be quite 
reasonable, but given there is an existing syntactic construct with 
quite different semantics today I find it objectionable.

YMMV.

David

On 27/08/2012 10:29 AM, Gregg Wonderly wrote:
>
> On Aug 24, 2012, at 7:27 PM, David Holmes<david.holmes at oracle.com>  wrote:
>
>> On 25/08/2012 3:03 AM, GREGG WONDERLY wrote:
>>>
>>> On Aug 23, 2012, at 8:00 PM, David Holmes<david.holmes at oracle.com>   wrote:
>>>
>>>> On 24/08/2012 12:56 AM, Peter Levart wrote:
>>>>> On Thursday, August 23, 2012 11:01:46 AM David Holmes wrote:
>>>>>> On 23/08/2012 8:13 AM, Brian Goetz wrote:
>>>>>>> The syntax was designed to be analogous to the "K.this.m()" syntax that
>>>>>>> is used in inner classes.
>>>>>>
>>>>>> But the semantics are quite different. K.this is a reference to a
>>>>>> completely different object (the enclosing instance from class K).
>>>>>> Whereas as K.super is meant to infer something about 'this'.
>>>>>
>>>>> 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.
>>>
>>> This view is troubling to me.  If we are in an inner class, and code
>>>
>>> OuterName.this.m();
>>>
>>> The compiler knows to look for the type OuterName in the hierarchy of class definitions visible to the inner class, and then invoke m().
>>
>> I don't see OuterName as telling the compiler where to look for something, it is simply naming something. The current object is "this", the enclosing instance is OuterName.this. It is not a search path it is a direct name for an object.
>
> The location of the statement tells the compiler what name space is visible to it.  I.e. it knows it is in an inner class, and thus it will look outward till it reaches the "outer" class, looking for the "OuterName" class.
>
>>> For default methods, if a we write
>>>
>>> OuterName.this.m();
>>>
>>> It seems to me that even though the compiler has to look in a slightly different way, the fully qualified name of OuterName is visible to it, so that it can ask "Is this a class" or "Is this an interface", and the take the appropriate steps to resolve what to invoke.
>>
>> Here OuterName.this does not name an enclosing instance. You are using the same syntax for two completely different things in my view.
>
> The context that this statement is in, specifies the "class" and interfaces which are visible in that context.  Thus, the "this" refers to the "context" which is the current "class", and thus it's implemented interfaces and thus the visible interfaces which can be reached.  If OuterName is not reachable in that namespace, the compiler can provide the appropriate error message.
>
>> No doubt compiler writers and parser writes think about this differently, but from my perspective as an end-programmer, these are quite different things. If I was explaining what this statement meant to someone the explanation in the two cases would be completely different - hence in my opinion the same syntax should not be used for both.
>
> The current details of "inner class" references to outer classes, in my view, is just one example of a context qualified reference to some more narrow scope, relative to the current class.
>
> I am, at this point, calling an interface, a special type of "class" definition, and thus I am thinking of interfaces and classes as having a common base, because we've now made abstract classes even more like interfaces.
>
> When I think about code wanting to access a specific "class" detail, we have several things that the language uses to control access.  We have very tedious things like introspection.  We have less tedious things like "public", "private" and package access.  The string, "OuterName.this", for me, is another one of these "control points".
>
> Maybe if you could provide a sentence or description that you'd say in a code review, or other moment that you'd talk about a code fragment for each of
>
> OuterName.this
>
> and
>
> OuterName.super
>
> that might help me really "get" how you are thinking about these two types of references, and why they seem so different in nature, that you'd prefer to add another keyword that is context sensitive into the mix.
>
> Gregg
>
>
>>
>>> Having the compiler do this small amount of introspection of the class/interface name space, seems like a lot better choice, then asking the developer to remember to type this vs super.
>>>
>>> What will be the compiler error message, if I type this instead of super or vice versa?  What will that do to help the developer really code effectively?
>>>
>>> Gregg
>