So I want to make my class identityless. But -- whoops! -- I released it
years ago and it has lots of usages. And though I've labeled it as
"value-based", any number of these callers are depending on its identity in
some way or other.
I'd like to put -- let's say an annotation on my class, like
`@
On Mon, Apr 25, 2022 at 7:52 PM Dan Smith wrote:
Yeah, I think this has to be the starting place, before we get into
> whatever other model simplifications, compatible migrations, etc., might be
> gained.
>
> The expectation for any two-types-for-one-name approach should be, I
> think, that almos
> On Apr 25, 2022, at 3:08 PM, Remi Forax wrote:
>
> Ok, maybe i've not understood correctly how B3 model works,
> for me being a B3 is a runtime property, not a type property.
>
> By example, if there is an Object but the VM knows the only possible type is
> a B3 and the value is not null then
On Apr 25, 2022, at 8:05 AM, Brian Goetz
mailto:brian.go...@oracle.com>> wrote:
Let’s state the opposing argument up front, because it was our starting point:
having to say “Complex.val” for 99% of the utterances of Complex would likely
be perceived as “boy those Java guys love their boilerplat
Ok, maybe i've not understood correctly how B3 model works,
for me being a B3 is a runtime property, not a type property.
By example, if there is an Object but the VM knows the only possible type is a
B3 and the value is not null then the VM is free to emit several stores,
because it's a B3, so
On Mon, Apr 25, 2022 at 3:56 PM Brian Goetz wrote:
> there are TWO users, the one who wrote the library, and the one using it
Yes, precisely. In the general case, these are distinct parties. In the
specific case, they'll sometimes be the same. The owner of a non-identity
class only gets to choos
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "Dan Heidinga" , "Kevin Bourrillion"
> , "valhalla-spec-experts"
>
> Sent: Monday, April 25, 2022 9:54:26 PM
> Subject: Re: [External] Foo / Foo.ref is a backward default; should be
> Foo.val /
> Foo
>> This seems very specific to Optional, for Op
I think this is getting out of hand.
Kevin presented a carefully thought out argument — which I am sure he spent
many hours on before sending — about why we might have (yet again) gotten the
defaults wrong. I think we owe it to Kevin (and all the Java developers) to
think as carefully about hi
> From: "Kevin Bourrillion"
> To: "valhalla-spec-experts"
> Sent: Monday, April 25, 2022 4:52:50 AM
> Subject: [External] Foo / Foo.ref is a backward default; should be Foo.val /
> Foo
> Hi,
> The current plan for `primitive class Foo` -- to call the value type `Foo` and
> the reference type `
I think this is one of the areas where opinions are going to differ, because
there is not necessarily a unitary notion of “the user”. In a small program
were one person wrote all the code, I agree that minimizing intrusion will make
that person happy. But Java’s strength is that it makes good
This seems very specific to Optional, for Optional storing null is always a
mistake, but that's not true for other VBC, by example a deadline can be typed
as an Instant with null meaning no deadline.
No, it is not specific to Optional at all. Many domains exclude null on an
ad-hoc basis.
It i
> From: "Brian Goetz"
> To: "Dan Heidinga"
> Cc: "Kevin Bourrillion" , "valhalla-spec-experts"
>
> Sent: Monday, April 25, 2022 8:26:02 PM
> Subject: Re: [External] Foo / Foo.ref is a backward default; should be
> Foo.val /
> Foo
>>> What I’m thinking here about migration is that existing APIs
On Mon, Apr 25, 2022 at 2:47 PM Dan Heidinga wrote:
As I said above, migration is one use case.
It's also only one of the 8 reasons I wrote up. 9 with Brian's.
Do we want to make this worse to read for the migration use case?
>
Yes, and for 8 other reasons!
--
Kevin Bourrillion | Java Lib
On Mon, Apr 25, 2022 at 1:53 PM Dan Heidinga wrote:
> Users who have already opted into using a B3 will be annoyed that they
> have to use the bad name to get what they already said they wanted.
>
> Users who want the default for B3 to be a reference should
> probably have picked a B2 alread
On Mon, Apr 25, 2022 at 1:59 PM Kevin Bourrillion wrote:
>
> On Mon, Apr 25, 2022 at 1:19 PM Brian Goetz wrote:
>>
>> Changing from a B2 -> B3 changes the default spelling from "L" -> "Q".
>> Why does this have to be done atomically?
>
> (First note that I'm thinking in terms of source compatibil
What I’m thinking here about migration is that existing APIs can say “Optional”
but field declarations can say Optional.val, getting additional footprint /
flattening benefits, without perturbing the APIs (and with cheap conversions.)
Aren't most of the migration cases (at least for existing VBC
On Mon, Apr 25, 2022 at 1:19 PM Brian Goetz wrote:
> Changing from a B2 -> B3 changes the default spelling from "L" -> "Q".
> Why does this have to be done atomically?
>
> (First note that I'm thinking in terms of source compatibility, if that
makes a difference.) I mostly just mean that anyone a
On Mon, Apr 25, 2022 at 1:19 PM Brian Goetz wrote:
>
> My understanding was we were going to guide most users towards B2
> values and would treat B3 as the rare, "expert" mode, for when density
> really matters. Does that decrease the education problem?
>
>
> I am not convinced it does, but am op
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
My understanding was we were going to guide most users towards B2
values and would treat B3 as the rare, "expert" mode, for when density
really matters. Does that decrease the education problem?
I am not convinced it does, but am open minded to see if there are other things
we can do at the decl
On Mon, Apr 25, 2022 at 10:05 AM Brian Goetz wrote:
Bucket 2 — This is the obvious migration target for value-based classes,
It also seems useful as the migration stepping-stone for bucket 1 -> 3.
Which makes me feel good about the possibility of shipping 2 first.
Bucket 3 — here’s where it g
> In the future world, which of these declarations do we expect to see?
>
> public final class Integer { … }
>
> or
>
> public mumble value class int { … }
>
> The tension is apparent here too; I think most Java developers would hope
> that, were we writing the world from scratch, that we’
- 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 t
> 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 discuss
> 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
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 swe
Let me give a brief overview of where things are with respect to flattening,
since some of this influences the user-model discussion Kevin has initiated.)
This is a very rough sketch, and not written for a general audience, so if
you’re tempted to post this to Twitter because it seems cool and
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 progra
tl:dr; I find pretty much everything about this compelling. And it comes at a
good time, too, because now that we’ve figured out what we can deliver, we can
figure out the sensible stacking of the object model.
As a refresher, recall that we’ve been loosely organizing classes into buckets:
B
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.exponen
30 matches
Mail list logo
