I need to do many more additional examples offline.
I appreciate your trying to make overriding of forwarders simpler for the jvm.
I would like to continue to explore the option having the jvm do the
calculation of overriding
both direct and indirect forwarders until we’ve worked more examples.
My original thought had been that this would benefit new code that knew it had to do something identity-full (lock, make weak references, etc) and wanted to enforce it would never see a value.
The migration path adds a cherry on top.
--Dan
- Original message -From: Brian Goetz To:
High-order tradeoffs:
- Having R/VObject be classes helps from the pedagogical perspective
(it paints an accurate map of the object model.)
- There were some anomalies raised that were the result of rewriting
an Object supertype to RefObject, and some concerns about "all our
tables got
A VM perspective:
*invocation*
*dynamic receiver*
*resolution*
*NOT invoked*
*selection:*
*actual execution*
invokevirtual D::m(LDT)
D
D.m(LDT)
D.m(LDT)
invokevirtual D::m(LDT)
E
D.m(LDT)
E.m(LDT)
reverser: adapt
This leads us to the next question, given that you can only override "locally"
a forwarder, what if a forwarder overrides a forwarder ? You throw a LinkageError ?
Yes, this could arise from inconsistent separate compilation (I thought
I covered this in my doc?) Best choice is probably to
- Mail original -
> De: "Brian Goetz"
> À: "Karen Kinnear"
> Cc: "valhalla-spec-experts"
> Envoyé: Vendredi 12 Avril 2019 01:04:15
> Objet: Re: Updated VM-bridges document
> On 4/11/2019 5:18 PM, Karen Kinnear wrote:
>>>
>>> OK, so at this point, the classfiles that have been loaded
