RefObject and ValObject

Remi Forax forax at
Mon Apr 15 13:15:29 UTC 2019

----- Mail original -----
> De: "Maurizio Cimadamore" <maurizio.cimadamore at>
> À: "Brian Goetz" <brian.goetz at>, "valhalla-spec-experts" <valhalla-spec-experts at>
> 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.

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


>> 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.)

More information about the valhalla-spec-observers mailing list