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.
I
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 l
- 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:
>>>
>&
On 4/11/2019 5:18 PM, Karen Kinnear wrote:
OK, so at this point, the classfiles that have been loaded look like:
class D {
void m(LDT) { real method }
@Forwarding(m(LDT)) abstract void m(Date);
}
class E extends D {
@Override
m(Date) { impl }
> On Apr 10, 2019, at 5:22 PM, Brian Goetz wrote:
>
> OK, so in the old world, D has m(Date).
>
>
> Now, D has m(LDT), with a forwarder from m(Date) -> m(LDT), with some sort of
> metadata stapled somewhere to effect the Date <--> LDT conversions.
>
>> class E extends D { m(Date); } whi
> De: "Brian Goetz"
> À: "valhalla-spec-experts"
> Envoyé: Jeudi 11 Avril 2019 21:52:23
> Objet: Re: Updated VM-bridges document
> This was received through a side channel:
>> From: [ mailto:sebastian.sickelm...@gmx.de | sebastian.sickelm...@gmx.de ]
&g
This was received through a side channel:
From: sebastian.sickelm...@gmx.de
Subject: Re: Updated VM-bridges document
Hi,
i have a question regarding the discussed forwarding schema for fields.
Should it be possible to forward field access to methods, so that
we can safely remove public fields
OK, so in the old world, D has m(Date).
Migration step 1: author: Date -> LocalDateTime
old class D { m(Date); }
Migration step 2: change method declarer: new class D {m(LDT);}
and javac creates a forwarder m(Date); -> Date->LDT/m(LDT);
Now, D has m(LDT), with a forwarder from m(Da
Brian,
Here is an example of when I believe we need to create a reverser - let me know
if my
assumptions don’t match yours.
Migration step 1: author: Date -> LocalDateTime
old class D { m(Date); }
Migration step 2: change method declarer: new class D {m(LDT);}
and javac creates a for
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Mardi 9 Avril 2019 15:39:19
> Objet: Re: Updated VM-bridges document
>>> OK, I see what you’re getting at now. Yes, this is one of the implementation
>>&g
> OK, I see what you’re getting at now. Yes, this is one of the implementation
> possibilities. I was mostly looking to validate the concepts before diving
> into the representational details. One key point is that the default case
> should be able to proceed with no bootstrap; a small set of
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 8 Avril 2019 20:39:03
> Objet: Re: Updated VM-bridges document
> OK, I see what you’re getting at now. Yes, this is one of the implementation
> possibili
result when overridden by legacy
subclasses.
> On Apr 8, 2019, at 1:18 PM, fo...@univ-mlv.fr wrote:
>
>
>
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 8 Avril 2019 16:24:21
> Objet: Re: Updated VM
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 8 Avril 2019 16:24:21
> Objet: Re: Updated VM-bridges document
>> The other thing is that Forwarding bridge should not use an adapter but a
>> bootst
>
> The other thing is that Forwarding bridge should not use an adapter but a
> bootstrap method.
Can you explain exactly what you mean here? Because in my mind, the adapter
_is_ a bootstrap method — it is code to which the VM upcalls at preparation /
link time to help establish linkage.
S
That’s just a typo. There’s just one attribute.
> On Apr 7, 2019, at 5:30 PM, Remi Forax wrote:
>
> Hi Brian,
> with an hat of JVM language implementor,
> the attribute ForwardingBridge is important because it allows to simulate
> things that are not co/contravariant for the VM but are from
Hi Brian,
with an hat of JVM language implementor,
the attribute ForwardingBridge is important because it allows to simulate
things that are not co/contravariant for the VM but are from the language point
of view, like between an int and a Long.
I don't see the point of having two attributes, gi
18 matches
Mail list logo