Syntax for calling super

Gregg Wonderly greggwon at
Sun Aug 26 17:29:41 PDT 2012

On Aug 24, 2012, at 7:27 PM, David Holmes <david.holmes at> wrote:

> On 25/08/2012 3:03 AM, GREGG WONDERLY wrote:
>> On Aug 23, 2012, at 8:00 PM, David Holmes<david.holmes at>  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 




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.


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

More information about the lambda-dev mailing list