What do you mean by synthesizing methods twice? Anyway, I can look into
modifying it to have Java.super() -- I might have to retain the "super$"
methods though, as I think the JVM verifier will reject a different class
trying to do INVOKESPECIAL for a super call - as far as I know, INVOKESPECIAL
can't call outside its own class hierarchy…
So basically, I would need to keep the super$Xxx methods in the adapter, and
the object returned from Java.super(adapter) would need to delegate to
adapter.super$Xxx. Then the only question is whether I keep the super$ methods
public and thus give two ways to people to invoke these methods, or make them
package private so only the Java.super() class can invoke them as part of the
delegation.
On Aug 21, 2013, at 2:09 PM, "Jim Laskey (Oracle)" <james.las...@oracle.com>
wrote:
> 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.szeg...@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.lagerg...@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.szeg...@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.
>>>
>>
>
