I've got a conflict tomorrow; let's cancel the EG meeting.
There are a few ongoing email discussions, in particular about the State of
Valhalla documents. If it's still useful, we can pick up those discussions next
time.
> On Jan 25, 2022, at 2:39 PM, Remi Forax wrote:
>
> I think we should revisit the idea of having the interfaces
> IdentityObject/ValueObject.
>
> They serve two purposes
> 1/ documentation: explain the difference between an identity class and a
> value class
And, in particular, describe the
I think we should revisit the idea of having the interfaces
IdentityObject/ValueObject.
They serve two purposes
1/ documentation: explain the difference between an identity class and a value
class
2/ type restriction: can be used as type or bound of type parameter for
algorithms that only
> From: "Brian Goetz"
> To: "Dan Heidinga"
> Cc: "Remi Forax" , "John Rose" ,
> "valhalla-spec-experts"
> Sent: Tuesday, January 25, 2022 3:57:17 PM
> Subject: Re: VM model and aconst_init
> The motivation for this comes from erasure. Even if we specialize, we need to
> be
> able to use
The motivation for this comes from erasure. Even if we specialize, we need to
be able to use specialized generics in an erased context, because there will be
erased clients. If we have
class Foo {
T m();
T[] arr();
}
we can use also sorts of bridging/casting tricks to
> Can you mix and match both modes in the same method?
> Probably, since the interpreter doesn’t care about
> multi-bytecode patterns. Dunno if this causes a testing
> problem, and if so how to fix it. I think it’s probably
> OK, especially if we require the two-way checkcast
> (Q-Foo not a
> From: "John Rose"
> To: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Sent: Wednesday, January 19, 2022 9:40:15 AM
> Subject: Re: VM model and aconst_init
> I think (based on our most recent conversations)
> that aconst_init can return a Q-type for B3 types
> and an L-type for B2 types. And
