My two cents on this topic:
Looking back at our previous models, the “identity” marker and the “inline”
marker
served two different and well identified purposes.
The “identity” marker signals that identity sensitive operations are allowed on
a
given type. This is a marker we absolutely need somehow (the alternative to
surround
all these operations with try { … } catch(IMSE e) … looks like a no-go).
The use case for an inline marker was to have the guarantee that a given type
can
never be null, allowing developers to skip null checks in their code and write
null-free algorithms. In the old model, it was achieved by accepting only
Q-types
which were guaranteed to be null-free.
But in the new model, this null-freeness cannot be guaranteed by the
InlineObject
interface, because it is … an interface! There's no plan to make all sub-types
of
InlineObject (including interfaces and abstract classes) null-free, and it
sounds
like a terrible idea to try to enforce this kind of rules.
Bottom line: I think we've already lost the benefits of having an “inline type”
marker,
so removing the “InlineObject” interface would simplify the model and would not
have a
negative impact on what developers can do with the new user model.
Fred
> On Apr 8, 2020, at 12:54, Brian Goetz <[email protected]> wrote:
>
> This is a good time to review the motivations for Identity/InlineObject, and
> see if there's anything we want to tweak about it.
>
> There are two main branches of the motivation here: pedagogical and
> functional.
>
> Pedagogically, we're asking users to amend their view of "object" to allow
> for some objects to have identity, and some objects to not have identity, and
> supertypes are one of the prime ways we capture these sorts of divisions.
> It's not an accident that we have both the informal statement "everything
> (except primitives) is an object" and the hierarchy constraint "all classes
> extend (implicitly or not) java.lang.Object". Not only is Object a place to
> hang the behavior that is common to all objects (equality, etc), its position
> at the root of the hierarchy sends a message that conditions how we think
> about objects. The intent of partitioning Object into IdentityObject and
> InlineObject is an attempt to capture the same.
>
> Functionally, there are operations that apply only to identity objects, such
> as identity equality, synchronization, Object::wait, etc. Some of these have
> been totalized appropriately (such as `==`); others are partial. Having
> synchronization be partial, without offering developers a way to express "if
> I tried to synchronize on this thing, would it throw", just makes Java less
> reliable, so we want a way to express identity both in the dynamic type
> system (`instanceof IdentityObject`) and the static type system (`<T extends
> IdentityObject>`).
>
> We also thought, at one point in time, that InlineObject and IdentityObject
> would be a sensible place to put new methods or default implementations of
> Object methods. However, as the design has evolved, the need for this has
> gone away. This opens the door to a new possibility, which I'd like to
> evaluate: just have one of them. (And, if we only have one, the move
> is forced: IdentityObject.)
>
> In this world, we'd just have IdentityObject, which would be viewed as a
> refinement of Object -- "Object, with identity". Identity classes would
> implement it implicitly, as today. The pedagogy would then be, instead of
> "there are two disjoint kinds of Object", be "Some objects are enhanced with
> identity." You'd still be able to say
>
> x instanceof IdentityObject
>
> and
>
> void foo(IdentityObject o) { ... }
>
> and
>
> class Foo<T extends IdentityObject> { ... }
>
> as a way of detecting the refinement, but not the opposite. So the questions
> are:
>
> - Pedagogically, does this help move users to the right mental model, or
> does the symmetric model do a better job?
> - Functionally, is there anything we might do with InlineObject, that we
> would miss?
>
> Secondarily:
>
> - If we take this step, is `IdentityObject` still the best name?
>
>
