Syntax for calling super

Ali Lahijani alahijani at gmail.com
Thu Aug 23 02:32:54 PDT 2012


I like  K.default, but suggest that K.interface might be more acceptable
with people trying to de-emphasize defaultness. That's for implemented
interfaces. The single superclass is simply "super".

The syntax seems more compelling when one considers this edge case when it
has to interact with the existing syntax for inner classes:

First have a look at a modified version of Zdeněk's plain old Java example:

class Parent {
    public void m() { System.out.println("Parent: " + hashCode()); }
}

public class Enclosing extends Parent {
    public void m() { System.out.println("Enclosing: " + hashCode()); }

    public class Inner extends Parent {
        public void m() { System.out.println("Inner: " + hashCode()); }

        public void doSomething() {
            this.m();
            super.m();

            Enclosing.this.m();
            Enclosing.super.m();
        }
    }
}

Test it with "new Enclosing().new Inner().doSomething();".

Now make Parent into an interface:

interface Parent {
    public void m() default { System.out.println("Parent: " + hashCode()); }
}

public class Enclosing implements Parent {
    public void m() { System.out.println("Enclosing: " + hashCode()); }

    public class Inner implements Parent {
        public void m() { System.out.println("Inner: " + hashCode()); }

        public void doSomething() {
            this.m();
            Parent.interface.m();

            Enclosing.this.m();
            Enclosing.Parent.interface.m();
        }
    }
}

The esoteric form Enclosing.Parent.interface.m() is needed to be
consistent Enclosing.super.m().

The idea is that Parent.interface should be a drop-in replacement for
"super".

Ali

On Thu, Aug 23, 2012 at 10:16 AM, "Zdeněk Troníček" <tronicek at fit.cvut.cz>wrote:

> In addition, K.super already means something else:
>
> class A {
>     int x;
> }
>
> class B extends A {
>     int x;
>     class B1 {
>         int x;
>         {
>             System.out.println(B.super.x); // refers to A.x
>             System.out.println(B.super.toString()); // calls A.toString()
>         }
>     }
> }
>
> What about K.default?
>
> Z.
> --
> Zdenek Tronicek
> FIT CTU in Prague
>
>
> David Holmes napsal(a):
> > 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'.
> >
> > If anything I think super.K.m() is more natural as an extension to the
> > existing super.m() notation.
> >
> > David
> > -----
> >
> >> One problem with the syntax you suggest is that unlike "this", "super"
> >> is not a valid expression.
> >>
> >> This would be made worse by the inconsistency it would introduce over
> >> "this"; currently ((K) this) has a meaning, and the role of casting to
> >> an enclosing (K) in that meaning would not be consistent with your
> >> suggestion for ((K) super).
> >>
> >> That said, we're not married to the K.super.m() syntax if there is an
> >> obviously better one.  On the other hand, we don't dislike the
> >> K.super.m() syntax either.
> >>
> >>
> >> On 8/22/2012 5:41 PM, Paul Benedict wrote:
> >>> This syntax caught my eye:
> >>>
> >>> interface K {
> >>>     int m() default { return 88; }
> >>> }
> >>>
> >>> interface J extends K {
> >>>     int m() default { return K.super.m(); }
> >>> }
> >>>
> >>> I really don't think it is is appropriate to code "K.super.m()". An
> >>> natural English reading of "K.super" would be "superclass of K" since
> >>> it is K that is qualified.... but that's not what the code intends to
> >>> be.
> >>>
> >>> I would recommend a casting syntax to make the intention clearer:
> >>> interface J extends K {
> >>>     int m() default { return ((K) super).m(); }
> >>> }
> >>>
> >>> Paul
> >>>
> >>
> >
> >
>
>
>


More information about the lambda-dev mailing list