On Mar 22, 2022, at 10:52 PM, Dan Smith
mailto:daniel.sm...@oracle.com>> wrote:
On Mar 22, 2022, at 7:21 PM, Dan Heidinga
mailto:heidi...@redhat.com>> wrote:
A couple of comments on the encoding and questions related to descriptors.
JVM proposal:
- Same conceptual framework.
- Classes can b
> From: "Brian Goetz"
> To: "daniel smith" , "valhalla-spec-experts"
>
> Sent: Thursday, March 24, 2022 1:46:44 PM
> Subject: Re: Alternative to IdentityObject & ValueObject interfaces
> On 3/23/2022 10:51 PM, Dan Smith wrote:
>>>
On 3/23/2022 10:51 PM, Dan Smith wrote:
On Mar 22, 2022, at 5:56 PM, Dan Smith wrote:
- Variable types: I don't see a good way to get the equivalent of an
'IdentityObject' type. It would involve tracking the 'identity'
property through the whole type system, which seems like a huge
burden
On Mar 22, 2022, at 5:56 PM, Dan Smith
mailto:daniel.sm...@oracle.com>> wrote:
- Variable types: I don't see a good way to get the equivalent of an
'IdentityObject' type. It would involve tracking the 'identity' property
through the whole type system, which seems like a huge burden for the
occ
My thinking on this topic has evolved a bit. At first, we thought about
conditional methods as being completely ad-hoc, such as:
interface List {
long sum();
}
Here, the sum() method exists as an island in various specializations.
This was practical in the first iteration of the te
(Sorry Dan, you're receiving this twice. I accidentally sent it off list first)
> Here's another more stable encoding, though, that feels less fiddly to me
> than what I originally wrote:
>
> ACC_VALUE means "allows value object instances"
>
> ACC_IDENTITY means "allows identity object instances
> As Dan points out, the main thing we give up by backing off from these
> interfaces is the static typing; we don't get to use `IdentityObject` as a
> parameter type, return type, or type bound. And the only reason we've come
> up with so far to want that is a pretty lame one -- locking.
Duri
- Original Message -
> From: "Maurizio Cimadamore"
> To: "daniel smith" , "valhalla-spec-experts"
>
> Sent: Wednesday, March 23, 2022 11:23:26 AM
> Subject: Re: Alternative to IdentityObject & ValueObject interfaces
> On 22/03/2022 2
lue object, do we really need to introduce a mechanism to separate them in
term of typing ?
Rémi
> From: "Brian Goetz"
> To: "daniel smith" , "valhalla-spec-experts"
>
> Sent: Wednesday, March 23, 2022 1:01:20 PM
> Subject: Re: Alternative to Id
Thanks Dan for putting the work in to provide a credible alternative.
Let me add some background for how we came up with these things. At
some point we asked ourselves, what if we had identity and value classes
from day 1? How would that affect the object model? And we concluded
at the time
On 22/03/2022 23:56, Dan Smith wrote:
Other abstract classes and interfaces are fine being neither (thus supporting
both kinds of subclasses).
I feel that for such a proposal to be really useful (but that's true for
the interface-based approach as well IMHO), you need a way for the _use
si
On Mar 22, 2022, at 7:44 PM, Kevin Bourrillion
mailto:kev...@google.com>> wrote:
On Tue, Mar 22, 2022 at 4:56 PM Dan Smith
mailto:daniel.sm...@oracle.com>> wrote:
In response to some encouragement from Remi, John, and others, I've decided to
take a closer look at how we might approach the cate
On Mar 22, 2022, at 7:21 PM, Dan Heidinga
mailto:heidi...@redhat.com>> wrote:
A couple of comments on the encoding and questions related to descriptors.
JVM proposal:
- Same conceptual framework.
- Classes can be ACC_VALUE, ACC_IDENTITY, or neither.
- Legacy-version classes are implicitly AC
On Tue, Mar 22, 2022 at 4:56 PM Dan Smith wrote:
In response to some encouragement from Remi, John, and others, I've decided
> to take a closer look at how we might approach the categorization of value
> and identity classes without relying on the IdentityObject and ValueObject
> interfaces.
>
>
A couple of comments on the encoding and questions related to descriptors.
>
> JVM proposal:
>
> - Same conceptual framework.
>
> - Classes can be ACC_VALUE, ACC_IDENTITY, or neither.
>
> - Legacy-version classes are implicitly ACC_IDENTITY. Legacy interfaces are
> not. Optionally, modern-version
In response to some encouragement from Remi, John, and others, I've decided to
take a closer look at how we might approach the categorization of value and
identity classes without relying on the IdentityObject and ValueObject
interfaces.
(For background, see the thread "The interfaces IdentityO
16 matches
Mail list logo
