design — which is a model
I think users can love, but requires us to go a little farther in what the VM
does to support it.
# Finding the Spirit of L-world
L-World is, at heart, an attempt to unify reference objects and
values; they're unified under a common top type (`Object`), a common
- Mail original -
> De: "Brian Goetz"
> À: "valhalla-spec-experts"
> Envoyé: Lundi 7 Janvier 2019 18:21:26
> Objet: Finding the spirit of L-World
> I’ve been processing the discussions at the Burlington meeting. While I think
> we made a lot o
that a field typed
as a L-type is not in fact a Q-type (or an array of L-type is not in fact an
array of Q-type).
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "valhalla-spec-experts"
> Envoyé: Lundi 7 Janvier 2019 18:21:26
> Objet: Finding the spir
Introducing a ValObject as super or having the ACC_VALUE bit are two
representation of the same thing for the VM.
In both case, we need to load the class to know if it's a value type or not,
and in Java, the class loading is delayed which works well for reference type
but not well for value
- Mail original -
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Mardi 8 Janvier 2019 14:03:18
> Objet: Re: Finding the spirit of L-World
>> Introducing a ValObject as super or having the ACC_VALUE bit
On 1/8/2019 11:20 AM, fo...@univ-mlv.fr wrote:
Right. And I'm saying, we can't sell that. Values should work like an
int; you can compare ints with ==. I think the "Currently" story
doesn't wash.
You can not use the "work like an int" argument here, a value type can contain
references, so
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Mardi 8 Janvier 2019 18:44:11
> Objet: Re: Finding the spirit of L-World
> On 1/8/2019 11:20 AM, [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] wrote:
>>> R
Thanks for writing this up Brian. It clearly lists a number of the problematic areas that were identified as potentially needing re-validation.
The key questions are around the mental model of what we're trying to accomplish and how to make it easy (easier?) for users to migrate to use value typ
> The key questions are around the mental model of what we're trying to
> accomplish and how to make it easy (easier?) for users to migrate to use
> value types or handle when their pre-value code is passed a valuetype.
> There's a cost for some group of users regardless of how we address each
More on substitutibility and why this it is desirable...
Equality
Now we need to define equality. The terminology is messy, as so many
of the terms we might want to use (object, value, instance) already
have associations. For now, we'll describe a _substitutability_
predicate on two insta
Thanks for bringing up .equals, and the possibility to ban == on values,
both of which have been touched on in the past but we've not really
focused much on these. It also helped me clarify why I think there's
really only one answer here.
As to equals(), having == be a substitutability test d
Forgot to comment on this:
And that means that equals() has become the substitutability test that
people WANT.
I agree with this completely. But, where I think I disagree (and this
is often the place where you and I reach for different tools) is that I
don't want to use the language spec t
On Feb 22, 2019, at 2:04 PM, Brian Goetz wrote:
> I want to have the language spec assign it a clear, precise, sound,
> principled meaning
+100
> most of these LIFE instances should, eventually, be replaced by plain old
> `x.equals(y)`.
FWIW, in some cases where y is a constant, the compar
On Feb 22, 2019, at 11:42 AM, Kevin Bourrillion wrote:
>
> I think we should make users write `equals` to test value types. If they
> write `==`, they are indicating a special situation where they need identity
> semantics, which don't make sense for value types, and that should be an
> error.
On Feb 22, 2019, at 6:57 PM, John Rose wrote:
>
> On Feb 22, 2019, at 11:42 AM, Kevin Bourrillion wrote:
>>
>> I think we should make users write `equals` to test value types. If they
>> write `==`, they are indicating a special situation where they need identity
>> semantics, which don't mak
On Jan 23, 2019, at 9:51 AM, Brian Goetz wrote:
>
>> Because values have no identity, in LW1 `System::identityHashCode`
>> throws `UnsupportedOperationException`. However, this is
>> unnecessarily harsh; for values, `identityHashCode` could simply
>> return `hashCode`. This would enable classes
- Mail original -
> De: "John Rose"
> À: "Kevin Bourrillion"
> Cc: "valhalla-spec-experts"
> Envoyé: Samedi 23 Février 2019 03:57:56
> Objet: Re: Finding the spirit of L-World
> On Feb 22, 2019, at 11:42 AM, Kevin Bourrillion wrote:
&
- Mail original -
> De: "John Rose"
> À: "Kevin Bourrillion"
> Cc: "valhalla-spec-experts"
> Envoyé: Samedi 23 Février 2019 04:02:15
> Objet: Re: Finding the spirit of L-World
> On Feb 22, 2019, at 6:57 PM, John Rose wrote:
>&g
On Feb 23, 2019, at 3:25 AM, Remi Forax wrote:
>
> This remember me another issue, we are discussing a lot about Java the
> language but that's not the only language that run on the JVM, by making acmp
> be an equivalent of substituableEquals() we are making a choice of semantics
> that may be
> class Object { ... }
> class RefObject extends Object { ... }
> class ValObject extends Object { ... }
Let’s talk about this one some more. There are some obvious practical benefits
of bringing these key concepts into the type system. The first is that talking
about ref vs value can be done
> De: "Brian Goetz"
> À: "valhalla-spec-experts"
> Envoyé: Jeudi 28 Février 2019 18:17:43
> Objet: Re: Finding the spirit of L-World
>> class Object { ... }
>> class RefObject extends Object { ... }
>> class ValObject extends Object { ... }
>
> the example from John,
> Object o = new Object();
> o instanceof RefObject
One way to fix this is: have `new Object` instantiate not an Object, but a
RefObject. (This sort of recognizes that Object is half interface, half class.)
The weird part is that then “new Object().getClass() != Obj
On Feb 28, 2019, at 10:13 AM, Brian Goetz wrote:
>
>> the example from John,
>> Object o = new Object();
>> o instanceof RefObject
>
> One way to fix this is: have `new Object` instantiate not an Object, but a
> RefObject. (This sort of recognizes that Object is half interface, half
> cla
One way to fix that and other reflective artifacts, is to piggy-back
on specialized generics and their refined type system. In the spirit
of brainstorming, let's pull on that string a bit.
We could declare that `RefObject` is a *species* of `Object`, not
a subclass. Then, `Object` is reveale
24 matches
Mail list logo
