Re: Objects vs. values, the continuation

[Kevin Bourrillion]

Thanks Dan!

On Mon, Apr 25, 2022 at 10:47 AM Dan Heidinga  wrote:

And I'm unclear on why the ephemeral information presentation is
> prefered to the Platonic meaning?
>

Indeed I've gotten this feedback before too. My response was that it's not
so much that one is "preferred", as that there just isn't much to say about
the other. 42 as a Platonic concept just sort of ... is?

But as a piece of *information* we can trace its flow throughout the code.
There is always some source speaking it and some sink hearing it (modulo
StatementExpressions). Frankly I don't know the terminology that people who
do data flow analysis would use here, but toward my goal of having a clear
picture of "what's happening inside my program" (that's at least a level
higher than things like registers), I've found this mental picture helpful.

*What* is it that gets lost by a StatementExpression, or by a second write
to a variable with no read in between? We came to see those as cases of
"value not used" in a very analogous sense to our long-existing checks for
"variable not used". Or in nullness analysis we have been looking at "where
can a null value flow in, and where can it flow out". Each "flowing" or
whatever that happened is of interest.

You could probably say that the thing I'm really describing is a single
"transmission" of a value and not a value itself. I do I agree that there
is *something* a little off about my presentation here.


I'm slightly concerned about the presentation of "small" as being
> incidental.  While size isn't a critical factor from the programming
> model perspective, it is incredibly important for aligning with the
> natural physics of the hardware.


> > The fact that these are "small" (at most 64 bits) is incidental, not
> essential; introducing a new quadruple type would not destabilize our
> concept of a primitive value.
>

Good point, thanks. Obviously I'm only attempting to pave the way for
seeing that compound values are still values, but I certainly don't mean to
imply we'd ever want a value that's 1000 bytes long. Upon looking at it
again, this text just seemed unnecessary and so I've nuked it.




> On Fri, Apr 22, 2022 at 6:38 PM Kevin Bourrillion 
> wrote:
> >
> > I'd like to remind everyone about this (self-important-sounding)
> document I shared some months ago: Data in Java programs: a basic
> conceptual model
> >
> > I may have undersold it a bit last time. True, it's not the final word
> on the only possible conceptual model anyone could ever form; however, it
> is at least a very extensively thought-out and reviewed and self-consistent
> one. I've also revised it a lot since you saw it (and it's still open for
> review). If nothing else, at least when I make arguments on this list you
> don't have to wonder what they are based on; I've laid it all out in black
> and white. And on that subject...
> >
> > The crux of that doc for Valhalla purposes is its clear separation
> between objects and values as wholly disjoint concepts.
> >
> > An object: has its own independent existence; is self-describing, thus
> can be polymorphic; is always indirected / accessed via reference; is
> eligible to have identity.
> >
> > A value: has no independent existence; is container-described, thus is
> strictly monomorphic; is always used directly / inline; cannot have
> identity. (Yes, I'm glossing over that references are also values, here.)
> >
> > What unifies objects and values (setting aside references) is that they
> are all instances.
> >
> > (First, to parrot Brian of a while ago: for a primitive type, the values
> are the instances of the type; for a reference type, the values are
> references to the instances of the type, those instances being objects.)
> >
> > Some instances are of a type that came from a class, so they get to have
> members. Some instances of are of a type that never used to have a class,
> but will now (int, etc.) -- yay. And some are of array types, which act
> like halfway-fake classes with a few halfway-fake members. Members for
> everybody, more or less!
> >
> > Though we have at times said "the goal of Valhalla is to make everything
> an object", I claim the unification we really want is for everything to be
> a class instance. I think that gives us enough common ground to focus on
> when we don't otherwise know which thing the thing is (e.g. with a type
> variable).
> >
> > One thing I like very much about this is that it fits perfectly with the
> fact that Integer is a subtype of Object and int is not.
> >
> > The way I think bucket 2 can and should be explained is: "in the
> programming model it absolutely is an object. In the performance model, the
> VM can replace it undetectably with a (compound) value. But that is behind
> the scenes; it's still behaviorally an object and don't feel bad about
> calling it an object." To me this is very simple and sensible.
> >
> > If we instead want to say "the int value 5 is an object now too", then
> we have some problems:

Re: [External] : Re: Objects vs. values, the continuation

[forax]

- Original Message -
> From: "Brian Goetz" 
> To: "Remi Forax" 
> Cc: "Kevin Bourrillion" , "valhalla-spec-experts" 
> 
> Sent: Monday, April 25, 2022 1:57:28 AM
> Subject: Re: [External] : Re: Objects vs. values, the continuation

> I agree totally, the former are semantic properties and the latter is a side
> effect of representation.  But that doesn’t help us much, because if people
> assume that these have the same finial field safety / integrity properties as
> reference objects, they will be in for a painful surprise.  So this has to be
> part of the story.

Interfaces in Golang are tearable and nobody care, i never seen somebody 
introducing interfaces in Go saying that they do not have integrity.

It's important when talking about the memory model, but first you have to talk 
about what is the memory model.

I think the fact that you can bypass constructor is a bigger deal that's why i 
still think that the compiler should add an empty constructor to the primitive 
class and do not allow the user to override it. 

Rémi

> 
> Sent from my iPad
> 
>> On Apr 24, 2022, at 6:30 PM, Remi Forax  wrote:
>> 
>> 
>> I think that having a default value / not being null is a property that is
> > easier to understand and easier to grasp than the concept of integrity.

Re: Objects vs. values, the continuation

[forax]

> From: "Kevin Bourrillion" 
> To: "Remi Forax" 
> Cc: "valhalla-spec-experts" 
> Sent: Monday, April 25, 2022 4:17:19 AM
> Subject: Re: Objects vs. values, the continuation

> On Sun, Apr 24, 2022 at 6:23 PM Remi Forax < [ mailto:fo...@univ-mlv.fr |
> fo...@univ-mlv.fr ] > wrote:

>> As we discussed earlier, there are two approaches, one is to say that
>> instance of class = object | value
>> the other is to say that
>> instance of class = object = reference object | immediate object

>> I prefer the later to the former, because it does not goes against what 
>> people
>> already think,

> Please let us not mistake this:

> BOTH choices involve redefining what a large number of people already think.
> That is inescapable and is part of the cost of doing this project.

> People think "all objects can be locked". We want to break that. They think
> "everything I can access members on is an object". I want to break that. They
> think "an object is always accessed via a reference". You want to break that.
> Etc. etc. This is just what happens when there's been a missing quadrant for
> decades.

You have to change some existing assumptions, that's true, but you are 
proposing a kind of refactoring of the world before adding a new concept. 
It's easier to introduce a new form of something already existing. 

>>> One thing I like very much about this is that it fits perfectly with the 
>>> fact
>>> that Integer is a subtype of Object and int is not.

>> I've not a clear idea how primitive will be retrofit to be "immediate class" 
>> but
>> at some point, we will want ArrayList to be valid with E still bounded 
>> by
>> Object, so the sentence "int is not a subtype of java.lang.Object" may be 
>> wrong
>> depending how we retrofit existing primitive types.

> No, this is my whole point. It's important for them to know that that is NOT
> subtyping. (The only kind of subtyping people know and the only kind they
> *should* think of is polymorphic subtyping.) They should continue to think of
> "A is a subtype of B" as meaning that they can interact with a B that is
> actually itself really an A; it's what Integer (but not int) gives you. This
> relationship is called something else ("extends", maybe?) and is what array
> covariance is also being rebased on.

Again, subtyping is already an existing concept, there is no win in trying to 
scooby-doo it. 
We are introducing a new way to do subtyping, the subtyping between a 
java.lang.Object and a QPoint; and it's a form of subtyping porlymophism given 
that you can call toString/equals and hashCode. 

Rémi 

128bits value type and VarHande.compareAndSet() Was: Objects vs. values, the continuation

[Remi Forax]

> From: "Brian Goetz" 
> To: "Dan Heidinga" 
> Cc: "Kevin Bourrillion" , "valhalla-spec-experts"
> 
> Sent: Monday, April 25, 2022 4:59:14 PM
> Subject: Re: Objects vs. values, the continuation

>>> The fact that these are "small" (at most 64 bits) is incidental, not 
>>> essential;
>>> introducing a new quadruple type would not destabilize our concept of a
>>> primitive value.

>> If we can tip the user's mental model so that they believe "small is
>> good" for B3 values, then we aid them in hitting the sweet space of
>> the design and help them avoid tearing issues. It doesn't change the
>> model but the more we can encourage the belief that B3 values should
>> be <= 64it the happier users will be with the results.

> I think its reasonable to say that “we can flatten 64 bits better than we can
> flatten 256, but go ahead and write the code you want, and we’ll do what we
> can.” Recent data suggests that we can get to 128 more quickly than we had
> initially expected, and (especially if we can drop the null footprint tax, as
> B3 does), you can do a lot in 128. Presumably in some future hardware
> generation this number will go up again, whether that is 5 or 10 years from
> now, we don’t know right now.

This is tangential but i write it here because i will forget again. 
There is an issue with representing B2 as a 128 bits value, while Intel and ARM 
both provides 128 atomic read/write if vectorized registers are used, they do 
not provide a CAS (or the equivament on ARM) on 128 bits. 

This is an issue for VarHandle because 
- one can create a VarHandle on any field (array cell), it does not have to be 
volatile (there is no way to declare the content of an array volatile) 
- VarHandle.compareAndSet() has to work. 

If we keep the exact same semantics for VarHandle, we can not use 128 bits for 
fields declared as B2 because a VarHandle may be constructed on it later. 

Rémi 

Re: Objects vs. values, the continuation

[Brian Goetz]

The fact that these are "small" (at most 64 bits) is incidental, not essential; 
introducing a new quadruple type would not destabilize our concept of a 
primitive value.

If we can tip the user's mental model so that they believe "small is
good" for B3 values, then we aid them in hitting the sweet space of
the design and help them avoid tearing issues.  It doesn't change the
model but the more we can encourage the belief that B3 values should
be <= 64it the happier users will be with the results.

I think its reasonable to say that “we can flatten 64 bits better than we can 
flatten 256, but go ahead and write the code you want, and we’ll do what we 
can.”  Recent data suggests that we can get to 128 more quickly than we had 
initially expected, and (especially if we can drop the null footprint tax, as 
B3 does), you can do a lot in 128.  Presumably in some future hardware 
generation this number will go up again, whether that is 5 or 10 years from 
now, we don’t know right now.

The tangible things I think we want permission from the user to do are:

 - drop identity
 - drop nullity
 - drop atomicity (non-tearing)

B2, as currently sketched, drops the first; B3.val further drops nullity and 
atomicity together.  Whether this is the right stacking is a good discussion to 
be having now, but ultimately we need permission for each of these.  While 
“small” objects may sidestep the atomicity constraint, we’d like this to remain 
an implementation detail, not an in-your-face aspect of the programming model.

Re: Objects vs. values, the continuation

[Dan Heidinga]

Hi Kevin,

A question about the "Values" subsection of the "Model" section.  You
draw a distinction between the Platonic value and values as ephemeral
pieces of information.

> A value is less than all that! It's just an ephemeral piece of information 
> being communicated directly from some program element to another.

and footnote 4

 >  "Value" has another, Platonic meaning: there is one and only one
value we call 42, transcending time and space and existence. In this
document I'm discussing a more specific meaning: how to think
concretely about a value inside a running Java program.

And I'm unclear on why the ephemeral information presentation is
prefered to the Platonic meaning?

Conceptually, all values with the same bits and type are
indistinguishable from one another. The locations are mutable, but the
values are effectively Platonic ideals.  Describing them as "summoned
from the Platonic plain" avoids having to try to make a distinction
against the common understanding of "ephemeral" as short-lived.  Does
leaning into the Platonic view ease the number of differences users
have to absorb?

I'm slightly concerned about the presentation of "small" as being
incidental.  While size isn't a critical factor from the programming
model perspective, it is incredibly important for aligning with the
natural physics of the hardware.

> The fact that these are "small" (at most 64 bits) is incidental, not 
> essential; introducing a new quadruple type would not destabilize our concept 
> of a primitive value.

If we can tip the user's mental model so that they believe "small is
good" for B3 values, then we aid them in hitting the sweet space of
the design and help them avoid tearing issues.  It doesn't change the
model but the more we can encourage the belief that B3 values should
be <= 64it the happier users will be with the results.

--Dan

On Fri, Apr 22, 2022 at 6:38 PM Kevin Bourrillion  wrote:
>
> I'd like to remind everyone about this (self-important-sounding) document I 
> shared some months ago: Data in Java programs: a basic conceptual model
>
> I may have undersold it a bit last time. True, it's not the final word on the 
> only possible conceptual model anyone could ever form; however, it is at 
> least a very extensively thought-out and reviewed and self-consistent one. 
> I've also revised it a lot since you saw it (and it's still open for review). 
> If nothing else, at least when I make arguments on this list you don't have 
> to wonder what they are based on; I've laid it all out in black and white. 
> And on that subject...
>
> The crux of that doc for Valhalla purposes is its clear separation between 
> objects and values as wholly disjoint concepts.
>
> An object: has its own independent existence; is self-describing, thus can be 
> polymorphic; is always indirected / accessed via reference; is eligible to 
> have identity.
>
> A value: has no independent existence; is container-described, thus is 
> strictly monomorphic; is always used directly / inline; cannot have identity. 
> (Yes, I'm glossing over that references are also values, here.)
>
> What unifies objects and values (setting aside references) is that they are 
> all instances.
>
> (First, to parrot Brian of a while ago: for a primitive type, the values are 
> the instances of the type; for a reference type, the values are references to 
> the instances of the type, those instances being objects.)
>
> Some instances are of a type that came from a class, so they get to have 
> members. Some instances of are of a type that never used to have a class, but 
> will now (int, etc.) -- yay. And some are of array types, which act like 
> halfway-fake classes with a few halfway-fake members. Members for everybody, 
> more or less!
>
> Though we have at times said "the goal of Valhalla is to make everything an 
> object", I claim the unification we really want is for everything to be a 
> class instance. I think that gives us enough common ground to focus on when 
> we don't otherwise know which thing the thing is (e.g. with a type variable).
>
> One thing I like very much about this is that it fits perfectly with the fact 
> that Integer is a subtype of Object and int is not.
>
> The way I think bucket 2 can and should be explained is: "in the programming 
> model it absolutely is an object. In the performance model, the VM can 
> replace it undetectably with a (compound) value. But that is behind the 
> scenes; it's still behaviorally an object and don't feel bad about calling it 
> an object." To me this is very simple and sensible.
>
> If we instead want to say "the int value 5 is an object now too", then we 
> have some problems:
>
> * I think it ruins those clean explanations just given
> * we'd need to coin some new term to mean exactly what I've just proposed 
> that "object" mean, and I have no idea what that would be (do you?)
>
> What are the latest thoughts on this?
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | 

Re: [External] : Re: Objects vs. values, the continuation

[Brian Goetz]

I think what is missing from our presentation — and likely key to succeeding — 
is how to describe “compound value” in a way that feels like a thing.

Well, a `double` is already a compound value that feels like a thing. Java just 
hides the internal structure instead of having us access d.exponent directly 
etc. Is that a useful angle? I'm not sure, but right now I think it is.

I wish I could be compelled by that argument (and I tried), but I can’t be.  I 
think if we asked 1M Java developers, pretty much all of them would say 
something like “double is a primitive 64 bit value”.  Yes, long and double have 
been allowed to tear forever, but (a) implementations have delivered 64 bit 
atomicity for almost forever, (b) most users don’t use long or double nearly as 
often as they use int, and (c) tearing is some weird concurrency black voodoo 
magic that people don’t want to pay attention to.  The upshot is that I suspect 
that only 0.001% of developers have actually spent any significant amount of 
time thinking about long and double tearing, let alone encountered it in the 
wild.  I don’t think we get away with “well, that could have happened with 
long, too.”

It gets worse when compound values “code like a class”, because they have 
constructors, and constructors exist to establish invariants.

It gets worse when we realize the only lesson of JCiP that most developers have 
internalized is “immutable classes are thread-safe.”  Having a weird new 
tearing behavior from immutable classes will be astonishing.  (One of the 
reasons to not allow capture of mutable locals back in the Lambda days was that 
would subject locals to data races — invalidating one of the few “free safe 
concurrency” guarantees we had.)

So I think we have to confront the tearing beast head on.

Re: Objects vs. values, the continuation

[Kevin Bourrillion]

On Sun, Apr 24, 2022 at 11:58 AM Brian Goetz  wrote:

I think what is missing from our presentation — and likely key to
> succeeding — is how to describe “compound value” in a way that feels like a
> thing.
>

Well, a `double` is already a compound value that feels like a thing. Java
just hides the internal structure instead of having us access d.exponent
directly etc. Is that a useful angle? I'm not sure, but right now I think
it is.



> Users mostly understand how primitives are different from objects, but
> “loose bag of primitives with limited integrity constraints” is a new and
> complex concept
>
that I worry users will have a hard time keeping separate from their
> conception of object.  Once we start aggregating fields, the temptation is
> to say “that’s like an object” and then carry with it some incorrect
> assumptions of integrity (e.g., final field guarantees)
>

Yes, no matter what there will be some list of mantras we have to try to
retrain people with. We want the list to be small, natural, learnable, but
we can't make it go away. So in what I propose, one of those mantras is

"my custom value types are like int, but composite(compound) --> an int was
never an object and it still isn't --> so neither are my value types"

(Of course, I'm still on the path that we *want* users to lean on their
existing understanding of int-vs.-Integer for understanding
MyType.val-vs.-MyType.ref, which I know has been controversial in the past.)

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com

Re: Objects vs. values, the continuation

[Kevin Bourrillion]

On Sun, Apr 24, 2022 at 6:23 PM Remi Forax  wrote:

As we discussed earlier, there are two approaches, one is to say that
>   instance of class = object | value
> the other is to say that
>   instance of class  = object = reference object | immediate object
>
> I prefer the later to the former, because it does not goes against what
> people already think,
>

Please let us not mistake this:

BOTH choices involve redefining what a large number of people already
think. That is inescapable and is part of the cost of doing this project.

People think "all objects can be locked". We want to break that. They think
"everything I can access members on is an object". I want to break that.
They think "an object is always accessed via a reference". You want to
break that. Etc. etc. This is just what happens when there's been a missing
quadrant for decades.

One thing I like very much about this is that it fits perfectly with the
> fact that Integer is a subtype of Object and int is not.
>
> I've not a clear idea how primitive will be retrofit to be "immediate
> class" but at some point, we will want ArrayList to be valid with E
> still bounded by Object, so the sentence "int is not a subtype of
> java.lang.Object" may be wrong depending how we retrofit existing primitive
> types.
>

No, this is my whole point. It's important for them to know that that is
NOT subtyping. (The only kind of subtyping people know and the only kind
they *should* think of is polymorphic subtyping.) They should continue to
think of "A is a subtype of B" as meaning that they can interact with a B
that is actually itself really an A; it's what Integer (but not int) gives
you. This relationship is called something else ("extends", maybe?) and is
what array covariance is also being rebased on.

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com

Re: [External] : Re: Objects vs. values, the continuation

[Brian Goetz]

I agree totally, the former are semantic properties and the latter is a side 
effect of representation.  But that doesn’t help us much, because if people 
assume that these have the same finial field safety / integrity properties as 
reference objects, they will be in for a painful surprise.  So this has to be 
part of the story.  

Sent from my iPad

> On Apr 24, 2022, at 6:30 PM, Remi Forax  wrote:
> 
> 
> I think that having a default value / not being null is a property that is 
> easier to understand and easier to grasp than the concept of integrity.

Re: Objects vs. values, the continuation

[Remi Forax]

> From: "Remi Forax" 
> To: "Kevin Bourrillion" 
> Cc: "valhalla-spec-experts" 
> Sent: Monday, April 25, 2022 12:23:32 AM
> Subject: Re: Objects vs. values, the continuation

>> From: "Kevin Bourrillion" 
>> To: "valhalla-spec-experts" 
>> Sent: Saturday, April 23, 2022 12:38:12 AM
>> Subject: Objects vs. values, the continuation

>> I'd like to remind everyone about this (self-important-sounding) document I
>> shared some months ago: [
>> https://docs.google.com/document/d/1J-a_K87P-R3TscD4uW2Qsbt5BlBR_7uX_BekwJ5BLSE/preview
>> | Data in Java programs: a basic conceptual model ]
>> I may have undersold it a bit last time. True, it's not the final word on the
>> only possible conceptual model anyone could ever form; however, it is at 
>> least
>> a very extensively thought-out and reviewed and self-consistent one. I've 
>> also
>> revised it a lot since you saw it (and it's still open for review). If 
>> nothing
>> else, at least when I make arguments on this list you don't have to wonder 
>> what
>> they are based on; I've laid it all out in black and white. And on that
>> subject...

>> The crux of that doc for Valhalla purposes is its clear separation between
>> objects and values as wholly disjoint concepts.

>> An object : has its own independent existence; is self-describing, thus can 
>> be
>> polymorphic; is always indirected / accessed via reference; is eligible to 
>> have
>> identity.

>> A value : has no independent existence; is container-described, thus is 
>> strictly
>> monomorphic; is always used directly / inline; cannot have identity. (Yes, 
>> I'm
>> glossing over that references are also values, here.)

>> What unifies objects and values (setting aside references) is that they are 
>> all
>> instances .

>> (First, to parrot Brian of a while ago: for a primitive type, the values are 
>> the
>> instances of the type; for a reference type, the values are references to the
>> instances of the type, those instances being objects.)

>> Some instances are of a type that came from a class, so they get to have 
>> members
>> . Some instances of are of a type that never used to have a class, but will 
>> now
>> (int, etc.) -- yay. And some are of array types, which act like halfway-fake
>> classes with a few halfway-fake members. Members for everybody, more or less!

>> Though we have at times said "the goal of Valhalla is to make everything an
>> object", I claim the unification we really want is for everything to be a 
>> class
>> instance. I think that gives us enough common ground to focus on when we 
>> don't
>> otherwise know which thing the thing is (e.g. with a type variable).

> As we discussed earlier, there are two approaches, one is to say that
> instance of class = object | value
> the other is to say that
> instance of class = object = reference object | immediate object

> I prefer the later to the former, because it does not goes against what people
> already think, said differently we add more vocabulary instead of trying to
> refine the existing vocabulary.

> I've done several talks on Valhalla,

(oops, part of that sentence went missing) 
I've done several talks on Valhalla, talking about value object or immediate 
object resonate more with the attendees than trying to redefine what an 
instance of a class is. 

Rémi 

Re: Objects vs. values, the continuation

[Remi Forax]

> From: "Brian Goetz" 
> To: "Kevin Bourrillion" 
> Cc: "valhalla-spec-experts" 
> Sent: Sunday, April 24, 2022 5:57:57 PM
> Subject: Re: Objects vs. values, the continuation

> Overall I find a lot to like about this presentation. I’m still a little iffy
> about whether we can redefine the letters o-b-j-e-c-t in this way, but that is
> largely a “syntax” reaction to your statements; the substance of the 
> statements
> sounds about right.

> I especially like this bit:

>> The way I think bucket 2 can and should be explained is: "in the programming
>> model it absolutely is an object. In the performance model , the VM can 
>> replace
>> it undetectably with a (compound) value. But that is behind the scenes; it's
>> still behaviorally an object and don't feel bad about calling it an object." 
>> To
>> me this is very simple and sensible.

> I think what is missing from our presentation — and likely key to succeeding —
> is how to describe “compound value” in a way that feels like a thing. Users
> mostly understand how primitives are different from objects, but “loose bag of
> primitives with limited integrity constraints” is a new and complex concept
> that I worry users will have a hard time keeping separate from their 
> conception
> of object. Once we start aggregating fields, the temptation is to say “that’s
> like an object” and then carry with it some incorrect assumptions of integrity
> (e.g., final field guarantees)

Having loose integrity is a property of primitive class but it's also a 
property of double and long. 
This is not how we describe long and double, at least not until we introduce 
the notion of concurrency. 

I think that having a default value / not being null is a property that is 
easier to understand and easier to grasp than the concept of integrity. 
Or maybe i'm not understanding what integrity really means. 

Rémi 

>> On Apr 22, 2022, at 6:38 PM, Kevin Bourrillion < [ mailto:kev...@google.com |
>> kev...@google.com ] > wrote:

>> I'd like to remind everyone about this (self-important-sounding) document I
>> shared some months ago: [
>> https://docs.google.com/document/d/1J-a_K87P-R3TscD4uW2Qsbt5BlBR_7uX_BekwJ5BLSE/preview
>> | Data in Java programs: a basic
>>  conceptual model ]

>> I may have undersold it a bit last time. True, it's not the final word on the
>> only possible conceptual model anyone could ever form; however, it is at 
>> least
>> a very extensively thought-out and reviewed and self-consistent one. I've 
>> also
>> revised it a lot since you saw it (and it's still open for review). If 
>> nothing
>> else, at least when I make arguments on this list you don't have to wonder 
>> what
>> they are based on; I've laid it all out in black and white. And on that
>> subject...

>> The crux of that doc for Valhalla purposes is its clear separation between
>> objects and values as wholly disjoint concepts.

>> An object : has its own independent existence; is self-describing, thus can 
>> be
>> polymorphic; is always indirected / accessed via reference; is eligible to 
>> have
>> identity.

>> A value : has no independent existence; is container-described, thus is 
>> strictly
>> monomorphic; is always used directly / inline; cannot have identity. (Yes, 
>> I'm
>> glossing over that references are also values, here.)

>> What unifies objects and values (setting aside references) is that they are 
>> all
>> instances .

>> (First, to parrot Brian of a while ago: for a primitive type, the values are 
>> the
>> instances of the type; for a reference type, the values are references to the
>> instances of the type, those instances being objects.)

>> Some instances are of a type that came from a class, so they get to have 
>> members
>> . Some instances of are of a type that never used to have a class, but will 
>> now
>> (int, etc.) -- yay. And some are of array types, which act like halfway-fake
>> classes with a few halfway-fake members. Members for everybody, more or less!

>> Though we have at times said "the goal of Valhalla is to make everything an
>> object", I claim the unification we really want is for everything to be a 
>> class
>> instance. I think that gives us enough common ground to focus on when we 
>> don't
>> otherwise know which thing the thing is (e.g. with a type variable).

>> One thing I like very much about this is that it fits perfectly with the fact
>> that Integer is a subtype of Object and int is not.

>> The way I think bucket 2 can and should be explained is: "in the programmi

Re: Objects vs. values, the continuation

[Remi Forax]

> From: "Kevin Bourrillion" 
> To: "valhalla-spec-experts" 
> Sent: Saturday, April 23, 2022 12:38:12 AM
> Subject: Objects vs. values, the continuation

> I'd like to remind everyone about this (self-important-sounding) document I
> shared some months ago: [
> https://docs.google.com/document/d/1J-a_K87P-R3TscD4uW2Qsbt5BlBR_7uX_BekwJ5BLSE/preview
> | Data in Java programs: a basic conceptual model ]
> I may have undersold it a bit last time. True, it's not the final word on the
> only possible conceptual model anyone could ever form; however, it is at least
> a very extensively thought-out and reviewed and self-consistent one. I've also
> revised it a lot since you saw it (and it's still open for review). If nothing
> else, at least when I make arguments on this list you don't have to wonder 
> what
> they are based on; I've laid it all out in black and white. And on that
> subject...

> The crux of that doc for Valhalla purposes is its clear separation between
> objects and values as wholly disjoint concepts.

> An object : has its own independent existence; is self-describing, thus can be
> polymorphic; is always indirected / accessed via reference; is eligible to 
> have
> identity.

> A value : has no independent existence; is container-described, thus is 
> strictly
> monomorphic; is always used directly / inline; cannot have identity. (Yes, I'm
> glossing over that references are also values, here.)

> What unifies objects and values (setting aside references) is that they are 
> all
> instances .

> (First, to parrot Brian of a while ago: for a primitive type, the values are 
> the
> instances of the type; for a reference type, the values are references to the
> instances of the type, those instances being objects.)

> Some instances are of a type that came from a class, so they get to have 
> members
> . Some instances of are of a type that never used to have a class, but will 
> now
> (int, etc.) -- yay. And some are of array types, which act like halfway-fake
> classes with a few halfway-fake members. Members for everybody, more or less!

> Though we have at times said "the goal of Valhalla is to make everything an
> object", I claim the unification we really want is for everything to be a 
> class
> instance. I think that gives us enough common ground to focus on when we don't
> otherwise know which thing the thing is (e.g. with a type variable).

As we discussed earlier, there are two approaches, one is to say that 
instance of class = object | value 
the other is to say that 
instance of class = object = reference object | immediate object 

I prefer the later to the former, because it does not goes against what people 
already think, said differently we add more vocabulary instead of trying to 
refine the existing vocabulary. 

I've done several talks on Valhalla, 

> One thing I like very much about this is that it fits perfectly with the fact
> that Integer is a subtype of Object and int is not.

I've not a clear idea how primitive will be retrofit to be "immediate class" 
but at some point, we will want ArrayList to be valid with E still bounded 
by Object, so the sentence "int is not a subtype of java.lang.Object" may be 
wrong depending how we retrofit existing primitive types. 

> The way I think bucket 2 can and should be explained is: "in the programming
> model it absolutely is an object. In the performance model , the VM can 
> replace
> it undetectably with a (compound) value. But that is behind the scenes; it's
> still behaviorally an object and don't feel bad about calling it an object." 
> To
> me this is very simple and sensible.

B2 are nullable immediate objects. 

> If we instead want to say "the int value 5 is an object now too", then we have
> some problems:

> * I think it ruins those clean explanations just given
> * we'd need to coin some new term to mean exactly what I've just proposed that
> "object" mean, and I have no idea what that would be (do you?)

> What are the latest thoughts on this?

I like "immediate" to characterize objects without a stable address in memory. 

Rémi 

Re: Objects vs. values, the continuation

[Brian Goetz]

Overall I find a lot to like about this presentation.   I’m still a little iffy 
about whether we can redefine the letters o-b-j-e-c-t in this way, but that is 
largely a “syntax” reaction to your statements; the substance of the statements 
sounds about right.

I especially like this bit:

The way I think bucket 2 can and should be explained is: "in the programming 
model it absolutely is an object. In the performance model, the VM can replace 
it undetectably with a (compound) value. But that is behind the scenes; it's 
still behaviorally an object and don't feel bad about calling it an object." To 
me this is very simple and sensible.

I think what is missing from our presentation — and likely key to succeeding — 
is how to describe “compound value” in a way that feels like a thing.  Users 
mostly understand how primitives are different from objects, but “loose bag of 
primitives with limited integrity constraints” is a new and complex concept 
that I worry users will have a hard time keeping separate from their conception 
of object.  Once we start aggregating fields, the temptation is to say “that’s 
like an object” and then carry with it some incorrect assumptions of integrity 
(e.g., final field guarantees)


On Apr 22, 2022, at 6:38 PM, Kevin Bourrillion 
mailto:kev...@google.com>> wrote:

I'd like to remind everyone about this (self-important-sounding) document I 
shared some months ago: Data in Java programs: a basic conceptual 
model

I may have undersold it a bit last time. True, it's not the final word on the 
only possible conceptual model anyone could ever form; however, it is at least 
a very extensively thought-out and reviewed and self-consistent one. I've also 
revised it a lot since you saw it (and it's still open for review). If nothing 
else, at least when I make arguments on this list you don't have to wonder what 
they are based on; I've laid it all out in black and white. And on that 
subject...

The crux of that doc for Valhalla purposes is its clear separation between 
objects and values as wholly disjoint concepts.

An object: has its own independent existence; is self-describing, thus can be 
polymorphic; is always indirected / accessed via reference; is eligible to have 
identity.

A value: has no independent existence; is container-described, thus is strictly 
monomorphic; is always used directly / inline; cannot have identity. (Yes, I'm 
glossing over that references are also values, here.)

What unifies objects and values (setting aside references) is that they are all 
instances.

(First, to parrot Brian of a while ago: for a primitive type, the values are 
the instances of the type; for a reference type, the values are references to 
the instances of the type, those instances being objects.)

Some instances are of a type that came from a class, so they get to have 
members. Some instances of are of a type that never used to have a class, but 
will now (int, etc.) -- yay. And some are of array types, which act like 
halfway-fake classes with a few halfway-fake members. Members for everybody, 
more or less!

Though we have at times said "the goal of Valhalla is to make everything an 
object", I claim the unification we really want is for everything to be a class 
instance. I think that gives us enough common ground to focus on when we don't 
otherwise know which thing the thing is (e.g. with a type variable).

One thing I like very much about this is that it fits perfectly with the fact 
that Integer is a subtype of Object and int is not.

The way I think bucket 2 can and should be explained is: "in the programming 
model it absolutely is an object. In the performance model, the VM can replace 
it undetectably with a (compound) value. But that is behind the scenes; it's 
still behaviorally an object and don't feel bad about calling it an object." To 
me this is very simple and sensible.

If we instead want to say "the int value 5 is an object now too", then we have 
some problems:

* I think it ruins those clean explanations just given
* we'd need to coin some new term to mean exactly what I've just proposed that 
"object" mean, and I have no idea what that would be (do you?)

What are the latest thoughts on this?

--
Kevin Bourrillion | Java Librarian | Google, Inc. | 
kev...@google.com

Objects vs. values, the continuation

[Kevin Bourrillion]

I'd like to remind everyone about this (self-important-sounding) document I
shared some months ago: Data in Java programs: a basic conceptual model


I may have undersold it a bit last time. True, it's not the final word on
the only possible conceptual model anyone could ever form; however, it is
at least a very extensively thought-out and reviewed and self-consistent
one. I've also revised it a lot since you saw it (and it's still open for
review). If nothing else, at least when I make arguments on this list you
don't have to wonder what they are based on; I've laid it all out in black
and white. And on that subject...

The crux of that doc for Valhalla purposes is its clear separation between
*objects* and *values* as wholly disjoint concepts.

An *object*: has its own independent existence; is self-describing, thus
can be polymorphic; is always indirected / accessed via reference; is
eligible to have identity.

A *value*: has no independent existence; is container-described, thus is
strictly monomorphic; is always used directly / inline; cannot have
identity. (Yes, I'm glossing over that references are also values, here.)

What *unifies* objects and values (setting aside references) is that they
are all *instances*.

(First, to parrot Brian of a while ago: for a primitive type, the values
are the instances of the type; for a reference type, the values are
references to the instances of the type, those instances being objects.)

Some instances are of a type that came from a class, so they get to have
*members*. Some instances of are of a type that never *used* to have a
class, but will now (int, etc.) -- yay. And some are of array types, which
act like halfway-fake classes with a few halfway-fake members. Members for
everybody, more or less!

Though we have at times said "the goal of Valhalla is to make everything an
object", I claim the unification we really want is for everything to be a
class instance. I think that gives us enough common ground to focus on when
we don't otherwise know which thing the thing is (e.g. with a type
variable).

One thing I like very much about this is that it fits perfectly with the
fact that Integer is a subtype of Object and int is not.

The way I think bucket 2 can and should be explained is: "in the *programming
model* it absolutely is an object. In the *performance model*, the VM can
replace it undetectably with a (compound) value. But that is behind the
scenes; it's still behaviorally an object and don't feel bad about calling
it an object." To me this is very simple and sensible.

If we instead want to say "the int value 5 is an object now too", then we
have some problems:

* I think it ruins those clean explanations just given
* we'd need to coin some new term to mean exactly what I've just proposed
that "object" mean, and I have no idea what that would be (do you?)

What are the latest thoughts on this?

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com