> I think i still prefer having interfaces Val/Ref instead of classes, these
> interfaces can be injected by the VM, at least the Ref interface can be
> injected, for the Val interface, we can requires all value types to implement
> that interface.
I view using interfaces instead of classes here as a fallback; it’s more
twitchy (VM now has to ensure that nothing implements both), it fails to “paint
the world as it is” (which I think has tremendous educational value), but most
importantly, it fails to give us an opportunity to put final methods in
{Ref,Val}Object.
For example, suppose we handled wait/notify by making ValObject.wait() be a
final method which throws. This lets us manage the constraint using tools we
already have — inheritance and final methods — rather than inventing yet more
special rules for what values can and cannot do. The more we can express in
the object model users are familiar with, the more users will be able to
immediately understand what is going on.
Now, maybe injecting superclasses will be so problematic that we give up, and
go with interfaces instead. That’s OK, but let’s be clear about what we’re
doing — that’s the “we gave up because the right thing was too hard” route.
