Review request for JDK-8023373

[Jim Laskey (Oracle)]

I lean toward 2) because of the elegance and consistency.  super$ looks hacked in.  I also like the fact you don't have to synthesize methods x2.  super should be reasonably rare.  I've only needed it once so far (using MethodHandle hack.)

Cheers,

-- Jim


On 2013-08-21, at 8:17 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> I was thinking of how to properly implement super calls. Basically, I had two ideas:
> 
> 1) add methods with prefix "super$" to adapters:
> 
> var cap = new java.io.FilterWriter(w) {
>    write: function(s, off, len) {
>        cap.super$write(capitalize(s), off, len)
>    }
> }
> 
> function capitalize(s) { ... } // capitalizes a string
> 
> (I'll use this "capitalizing writer" example throughout)
> 
> 2) Add a separate Java.super() function that creates a super-invoking adapter for another adapter:
> 
> var cap = new java.io.FilterWriter(w) {
>    write: function(s, off, len) {
>        cap_super.write(capitalize(s), off, len)
>    }
> }
> var cap_super = Java.super(cap)
> 
> Solution (1) seems simpler to use and is simpler to implement. It is also apparently compatible with how Rhino exposes super methods. Solution (2) has the advantage of not introducing synthetic identifiers into the method namespace of adapters. From conceptual elegance point of view, I'd say (2), but my pragmatic self nudges me towards (1). For a while I was hoping I can sneak in the result of Java.super() into the literal itself and thus avoid using cap_super as another top-level identifier, like this:
> 
> var cap = new java.io.FilterWriter(w) {
>    super: Java.super(cap),
>    write: function(s, off, len) {
>        this.super.write(capitalize(s), off, len)
>    }
> }
> 
> but unfortunately, this doesn't fly: cap is not yet defined when Java.super(cap) is evaluated, and it'd require using the somewhat awkward looking "this.super." construct too. That said, I can still add Java.super() if people think it'd be nicer; the two are actually not even mutually exclusive.
> 
> Attila.
> 
> On Aug 21, 2013, at 1:07 PM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:
> 
>> +1. It would be nice if we had a more consistent way to express it like Java.super or something, though, for consistency. Even though Rhino does it this way. What do you other guys think?
>> 
>> /M
>> 
>> On Aug 21, 2013, at 11:19 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>> 
>>> Please review JDK-8023373 at http://cr.openjdk.java.net/~attila/8023373/webrev.00
>>> 
>>> Much of the change is just refactoring -- we already had code for emitting super calls, as overridable methods that did not have an overridde specified by an adapter instance had to delegate to the super call, so the change really was to extract it into emitSuperCall() method, which in turn made generateSuperMethod() really trivial. The rest of the changes in generateMethod() are really just  refactorings, and moving some code around (e.g. definition of nextLocalVar was moved closer to the point where it was used). 
>>> 
>>> Thanks,
>>> Attila.
>> 
>