>
> Your idea of treating Object as abstract is, I believe, a sound one (which
> doesn't need any extra rule) - but we might have to figure out some story for
> anonymous inner classes of the kind `new Object() { ... }`.
After thinking about it for all of five minutes, I think this may have broken
the logjam (or, at least the current logjam.). We’ve been asking ourselves
whether RO/VO are classes or interfaces, when we didn’t really consider
abstract classes. Which we didn’t consider because we had assumed that the
concrete-ness of Object was nailed down. Let’s assume it’s not.
Then we have:
abstract class Object { }
abstract class RefObject <: Object { }
abstract class ValObject <: Object { }
Existing classes that extend Object are silently reparented to RefObject, both
at compile time and runtime. This may have some small .getSuperclass()
anomalies but this seems pretty minor. Same with anon classes of Object.
Inline classes implicitly extend ValObject.
We add a method `Object::newInstance` (name to be bikeshod later.). We start
warning in the compiler on `new Object`, to motivate migration to
`Object::newInstance`. Runtime rewrites these too.
There are some minor behavioral compatibility issues here, but they seem pretty
minor, and in the end, we end up with a hierarchy that describes the way we
want users to see the type system.
