> From: "John Rose"
> To: "daniel smith"
> Cc: "Kevin Bourrillion" , "Brian Goetz"
> , "valhalla-spec-experts"
>
> Sent: Jeudi 4 Novembre 2021 02:34:52
> Subject: Re: [External] : Re: Consolidating the user model
>
An implication of universal generics is that there needs to be
some common protocol that works on both vals and refs. In the
val/ref model, that protocol is objects: both vals and refs are
objects with members that can be accessed via '.'. In the
value/object model, I'm not
On Thu, Nov 4, 2021 at 9:28 AM Dan Smith wrote:
> On Nov 3, 2021, at 6:19 PM, Kevin Bourrillion wrote:
>
> I think my intuitions about boxes tie heavily to 'getClass' behavior (or
>> some analogous reflective operation). "What are you?" should give me
>> different answers for a bare value and a
On Nov 4, 2021, at 10:08 AM, Kevin Bourrillion
mailto:kev...@google.com>> wrote:
Your model is likely enough the best, and I'm simply "resisting" it, but in
that case I'm channeling some of the resistance other users will feel, and we
can hash out how to head it off. But also, occasionally I
On Nov 3, 2021, at 7:34 PM, John Rose
mailto:john.r.r...@oracle.com>> wrote:
There’s a bigger hiccup when you compare all that with good old int:
int iv = 42; // “class int” is NOT a thing, but “class Integer” is
assert iv.getClass() != int.class; // because int is not a class
assert
On Nov 3, 2021, at 6:19 PM, Kevin Bourrillion
mailto:kev...@google.com>> wrote:
I think my intuitions about boxes tie heavily to 'getClass' behavior (or some
analogous reflective operation). "What are you?" should give me different
answers for a bare value and a box. A duck in a box is not the
On Thu, Nov 4, 2021 at 7:56 AM Brian Goetz wrote:
On 11/4/2021 2:54 AM, Kevin Bourrillion wrote:
>
> Point.ref pr = pv; // same object… now it’s on the heap, though, with a
>> real live heap header
>> assert pr.getClass() == Point.class; // same class, but...
>>
>
> Why would we even want
I would summarize what you've been on about as "Hey, developers are used
to primitives and boxes, is there mileage in working within that
framework, rather than tossing it out the window because boxes seem
dirty?" And I think there is something to that.
One way to frame this is that there's
To close the loop, in the initial "Eclair" discussion (which grew out of
a conversation at the last JVMLS), a primitive was a pair of classes,
where the companion class was actually an interface. We haven't
revisited "what is Point.ref" since then, but one possible way to do
this is to say
On 11/4/2021 2:54 AM, Kevin Bourrillion wrote:
Point.ref pr = pv; // same object… now it’s on the heap, though,
with a real live heap header
assert pr.getClass() == Point.class; // same class, but...
Why would we even want this? It would be very surprising/puzzling to me.
On Wed, Nov 3, 2021 at 6:35 PM John Rose wrote:
Let’s see what happens if we say that (a) bare values have headers
>
and (b) Object::getClass allows the user to observe part of the header
> contents.
>
I'm asking specific questions below as best I can, but I must confess that
I don't really
On Tue, Nov 2, 2021 at 4:53 PM Brian Goetz wrote:
## Reflection
>>
>> Earlier designs all included some non-intuitive behavior around
>> reflection.
>> What we'd like to do is align the user-visible types with reflection
>> literals
>> with descriptors, following the invariant that
>>
>>
On Nov 3, 2021, at 4:05 PM, Dan Smith
mailto:daniel.sm...@oracle.com>> wrote:
(It is, I suppose, part of the model that objects of a given class all have a
finite, matching layout when accessed by value, even if the details of that
layout are kept abstract. Which is why value types are
(Note that shipping bucket-2 shouldn't require us to agree on any of this
stuff below.)
On Wed, Nov 3, 2021 at 4:06 PM Dan Smith wrote:
> - provides the exact same API as the original
>> - has the exact same behaviors as the original
>>
>
> Agreed that Point and Point.ref are different types
On Nov 3, 2021, at 3:40 PM, Kevin Bourrillion
mailto:kev...@google.com>> wrote:
The problem is that you want to say that the Point gets converted to some other
thing, yet that other thing:
- is == to the original
I would hope that's already true of int==Integer?
Formally, you can't literally
On Nov 3, 2021, at 11:34 AM, Brian Goetz wrote:
>
> There's lots of great stuff on subtyping in chapters 15 and 16 of TAPL (esp
> 15.6, "Coercion semantics"), which might be helpful. But as a tl;dr, I would
> suggest treating subtyping strictly as an is-a relation within our nominal
> type
There's lots of great stuff on subtyping in chapters 15 and 16 of TAPL
(esp 15.6, "Coercion semantics"), which might be helpful. But as a
tl;dr, I would suggest treating subtyping strictly as an is-a relation
within our nominal type system. By this interpretation, int and int
Subtyping is a
On Nov 3, 2021, at 10:23 AM, Kevin Bourrillion
mailto:kev...@google.com>> wrote:
I think this fits neatly with the current design: `Point` has no supertypes*,
not even `Object`, but `Point.ref` does.
(*I mean "supertype" in the polymorphic sense, not the "has a conversion" sense
or the "can
On Wed, Nov 3, 2021 at 9:02 AM John Rose wrote:
> One way to thicken this thin argument is to say that Point is not really
a class.
> It’s a primitive. Then it still has a value-set inclusion relation to
Object, but it’s
> not a sub-class of Object. It is a value-set subtype.
I would spin it
On Nov 2, 2021, at 4:53 PM, Brian Goetz
mailto:brian.go...@oracle.com>> wrote:
Actually, that makes me start to wonder if `getClass()` should be another
method like `notify` that simply doesn't make sense to call on value types.
(But we still need the two distinct Class instances per class
I really like this, it's far better than how i was seeing Valhalla,
pushing .ref into a corner is a good move.
Yes, we always disliked how prevalent .ref was; it took several rounds
of "shaking the box" to get it to stay in the corner.
I still hope that moving from B1 to B2 can be almost
I haven't caught up on the plans for equality in a long time.
This is a good time to catch up on this.
Today, the JVM provides an equality operation on objects in the form of
the `ACMP` instructions. It also provides per-primitive equality
operations (`ICMP`, `FCMP`, etc) for the various
My concern is that the purest form of value types will be overused and
misused for even less clear-cut cases. I would like to think that we
can convince these users that they really want the next "bucket" over,
which I think comes down to whether the added cost of `null` is worth it.
I
23 matches
Mail list logo
