Finding the spirit of L-World

[Ryan Schmitt]

>From a language user's perspective, I find it strange that a widening
conversion from ValObject to Object would give me *more* abilities (such as
synchronization), rather than less:

    ValObject v = ...;
    synchronized (v) { ... } // (presumably) fails to compile
    Object o = v; // widening conversion
    synchronized (o) { ... } // presumably compiles

What if this were flipped around?

    interface ValObject { ... }
    interface RefObject { ... }
    class Object implements RefObject, ValObject { ... } // values are
objects now!

    Object o = new Point(...);
    synchronized (o) { ... } // so far so good
    ValObject v = (ValObject) o; // narrowing conversion; I can now do
fewer things
    synchronized (v) { ... } // fails to compile
    RefObject r = (RefObject) o; // ClassCastException


On Thu, Feb 28, 2019 at 9:20 AM Brian Goetz <brian.goetz at oracle.com> wrote:

>
> > class Object { ... }
> > class RefObject extends Object { ... }
> > class ValObject extends Object { ... }
>
> Let’s talk about this one some more.  There are some obvious practical
> benefits of bringing these key concepts into the type system.  The first is
> that talking about ref vs value can be done with tools we already have:
>
>     if (x instanceof RefObject) { synchronized(x) { … } }
>
>     void m(ValObject vo) { … }
>
>     class Foo<T extends ValObject> { … }
>
> rather than inventing new ways to talk about “ref only” or “val only”.
>
> Another is that ref- or val-specific behavior has an obvious place to
> live, and can be implemented with tools we already have (e.g., final
> methods.)
>
> A third is that all objects are no longer created equally; having the “top
> types” reflect this will help users learn and understand this.
>
> A minor benefit is we no longer need an ACC_VALUE flag; we can just
> trigger off of “extends ValObject”.
>
>
> So, what are the costs and risks?
>
>  - JVMs have to rewrite hierarchies so when a class is loaded that extends
> Object, it is rewritten to extend RefObject.
>  - Existing code that relies on .getSuperclass() == Object.class might
> break.
>  - Inheritance hierarchies get one deeper, making searches of superclass
> chains one longer.
>
> Any others?
>
>
>
>