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