Forward declaring the identity of an object

[David Alayachew]

Hello RedIODev,

Thank you for your response!

> I see you though of it as a compile time thing. But like
> you also mentioned it would be difficult for the compiler
> to prove that no access occurs before initialization
> severely limiting the usefulness.

More or less, though I wouldn't use the word "usefulness", but instead,
"safety". Ultimately, the usefulness remains, it just becomes way more
periless because the compiler can only protect you from so much.

> Also the things with for example instanceof and
> synchronization are real questions as they primary
> operate on identity and don't use the (garbage) data of a
> half initialized object.
>
> Like:
>
> Foo foo = __uninitialized;
> boolean b = foo instanceof Foo //true or false
> syncronized(foo) { //works or not?
>
> }
> foo = new Foo();

Good point. Let me correct myself then.

What if we reworked things like this instead. Rather than saying
__uninitialized, what if we said something like temp-null, which I think is
a garbage syntax, but it communicates the point more clearly.

Basically, you literally set the value to null, which answers all the
questions about what will happen if the uninitialized value gets passed in.
The only difference is that, if we use temp-null instead of just null, then
in the case of final fields, the compiler is permitted to set that variable
one more time, this time to the actual value, whether that's actually null,
or the constructor's output, etc.

Then, once we finally initialize the value, the runtime will go back to all
of the locations that we set to null via temp-null, and overwrite that with
the actual memory location.

So in your hypothetical example, if you switched out Foo foo for final Foo
foo, then everything should make sense because it becomes obvious how the
program works. That would simplify things significantly, because we're
leaning on existing semantics that every Java developer already understands.

> Also in terms of value objects and primitives it doesn't
> really work at all since they by definition do not have
> identity (in Java) so since they cannot be referenced at
> all they can't ever be in this uninitialized state.
>
> Overall cyclical REFERENCE structures don't make sense or
> work in datatypes without identity.

100% agreed.

This is actually kind of an interesting point because it helps quantify the
benefits that identity actually gives you. Sometimes, with all the Valhalla
stuff coming out, it almost feels like Identity Objects are somehow
inferior to these new value objects. Yes, there's obviously tradeoffs, but
the benefits of identity feel like minimal benefits that you only opt into
when absolutely necessary (mutability, which is falling out of
favor/inheritance, which has long since fallen out of
favor/synchronization, which isn't something you throw into every day code,
etc.). Being able to represent complex relationships more directly and
easily makes me feel like identity has actual strengths that are worth
considering for more than 5 seconds when thinking about how to model my
everyday code. And it would be very easy to switch between a value class to
an identity class if the need arises, so already, this addresses many of
the maintainability issues I brought up in the other thread above.

I feel like if we were to allow identity classes to have this feature, then
identity classes would have an actual argument for being used in everyday
code aside from when Java forces you to use them.

> The only big obstacle I see is that it's probably not
> worth the cost of implementating. The private field or id
> approach both work and solve the problem hence this is
> merely a convenience feature, even though the concept
> might allow unforeseen possibilities not obvious right
> now. If other problems are found that would be solved
> with it it might become viable to implement.

I hear you.

Part of the reason why I continue to push this feature is because, not only
do I think that this is a powerful feature that uproots a lot of complexity
involved in how programmer's think about relationships, but I am starting
to suspect that this is a surprisingly simple feature to implement.

I am gambling that this will be a low cost, high gain feature, which will
justify it being worked on, even if not now (String templates and whatnot
are higher priority).

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230707/087c442c/attachment-0001.htm>