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 ]
>> Subject: Re: Updated VM-bridges document
To me, getting fancy here sounds like borrowing trouble; it seems much
simpler -- and perfectly reasonable -- to reject cycles at both compile
and runtime, and let users use `V?` in the place they want to break
their cycles. (Assuming we're comfortable with `V?` means not
flattened, which is t
> On Apr 11, 2019, at 15:20, Karen Kinnear wrote:
>
> 2. circularity handling for value type fields - proposed experiment with vm
> detection
> Remi: if VM determines where to “stop” flattening the results will be random
> locations - which will change performance
> Karen: Frederic prototyping
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
Attendees: Remi, Tobi, Dan H, John, Brian, Simms, Frederic, Karen
AIs:
1. Remi - list of P3 bugs for condy rfes
2. Remi - Amber combinator suggestion
3. Karen - forwarder example for which we will need a reverser
4. editor note - I asked Frederic to forward an example of random
flattening/perform
