----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadam...@oracle.com>
> À: "Brian Goetz" <brian.go...@oracle.com>, "valhalla-spec-experts"
> <valhalla-spec-experts@openjdk.java.net>
> Envoyé: Lundi 15 Avril 2019 14:20:35
> Objet: Re: RefObject and ValObject
> On 15/04/2019 13:06, Brian Goetz wrote:
>>
>>
>>> But it seems like we have already ruled this out - since, if
>>> typeof(new Object()) is 'RefObject', you don't want RefObject <: Object.
>>
>> I think you misunderstood the "want" here (though it still may not be
>> possible.)
>>
>> The desired model is:
>> - Object is the top type. Everything is an Object.
>> - Some objects have identity (RefObject), others do not (ValObject).
>> But they are all Object.
>>
>> This means we want {Ref,Val}Object <: Object. (Whether they are
>> interface or class or something else.)
>
> Seems like I've read this requirement:
>
> "but we don’t want Object <: RefObject for obvious reasons"
>
> backwards. So, what this means is that it would be type-sound regardless
> of interface vs. class choice. But the other concerns remain, e.g. as to
> the fact that the boundary between reinterpreted types (Object as
> RefObject) and non-reinterpreted types (Object as top type) seems very
> fuzzy.
yes,
divorcing the runtime class from the type is something we can do, but it's not
because we can do that we should,
as a teacher you usually don't want to talk about the difference between a
class and a type until you have reached the subtyping chapter.
The initial goal is to make the concept of ref type and value type easier to
grasp by providing a simple hierarchy, but new Object() can not be retconed to
a RefObject easily, so it's not that simple.
And Ruby has tried to do something similar by introducing BasicObject in 1.9
(for another reason, because scopes are liked to classes in Ruby), at the end
few people cares, so we have to be careful to not introduce something that will
be a hurdle in compatibility for in the end no benefit.
So we need to be able to have types representing any Object, ref Object and
value Object, but i think that RefObject and ValObject are not the only
solution for that.
>
> Maurizio
Rémi
>
>>
>> One of the main reasons for wanting this setup is that it reflects the
>> desired reality: everything is an object, but some are special objects
>> (those with identity.) The addition of value types is a big
>> perturbation to the type system; reflecting it this way makes the
>> object hierarchy reflect the reality and the desired intuition, and
>> makes the distinction between ref/val slightly less magic.
>>
>> (There are other reasons too; for example, wouldn't it be nice if
>> ValObject.{wait,notify,notifyAll} were _ordinary final methods_ that
>> threw in ValObject? Again, slightly less magic.)
>>
