Valhalla EG notes Jan 16, 2019

[Brian Goetz]

>  Option 2: RefObject, ValObject - interfaces
>    VM at class definition adds RefObject to all existing classes
>    value classes required to declare ValObject as superinterface
> 
>    ackwardness: VM needs special behaviors for Object.wait, Object.notify - if dynamically a ValObject, throw IMSE
>      instead of having that obvious from the implementation in a superclass.
> 
> Are there other concerns here?
> This seems cleaner to me - especially since I also believe that synchronization on ValObjects will also require
> special handling - which will be vm implementations rather than visible in java sources (exact plan is TBD).

As I said to Remi, let’s be crystal clear that this seems cleaner _only to VM implementors_.  To everyone else, it’s less clean, less powerful, less educational, and more complicated (“why can’t I implement both RefObject and ValObject?”)  

If we bash our heads against the former for a while and give up, that’s OK; we can’t solve all the problems all the time.  But let’s be clear what we’re doing, and why.  

Theres’s also a middle ground: ValObject is a class, and RefObject is an interface.  While this may appear stupid, it reclaims more than half of what we lose by making both interfaces — because it gives us a place to put privileged, final, value-specific behaviors.  And values are going to need more of them than references will.