Forward declaring the identity of an object

[David Alayachew]

Hello RedIODev,

Thank you for your response!

> The "change the variable itself afterwards" idea also is
> the reason you think the keyword should be at the use
> site.
>
> But this puts all the work and the track keeping to the
> runtime which now has to keep a list of what fields
> belong to this delayed object. Something the memory
> address (field) is already doing by itself in case of a
> valid object.
>
> So the simpler and more logical approach is to just set
> the field to the already prepared memory location the
> object will be initialized to. But mark that location so
> it will be treated as null if accessed through a field.
> This requires only 1 note for the runtime per object
> instead of per field.
>
> I don't know if you are familiar with C but here are the
> 2 approaches modeled in C:
>
> your approach:
>
> Foo* foo = null;
> Foo* foo2 = null;
>
> //runtime remembers fields
> Foo** __foo_field = &foo;
> Foo** __foo_field2 = &foo2;
>
> // some stuff
>
> //foo init
> Foo* actual_foo = malloc(sizeof(Foo));
> init_foo(actual_foo);
>
> // setting of every forwarded declare field
> *__foo_field = actual_foo;
> *__foo_field2 = actual_foo;
>
> // runtime forgetting now fully init fields.
> Foo** __foo_field = nullptr;
> Foo** __foo_field2 = nullptr;
>
> My approach:
>
> Foo* actual_foo = malloc(sizeof(Foo));
> Foo* foo = actual_foo;
> Foo* foo2 = actual_foo;
>
> //Runtime remembers memory as not initialized
> Foo* uninit_memory = actual_foo;
>
> //Some stuff
>
> //foo init
> init_foo(uninnit_memory);
>
> // runtime forgetting now initialized memory
> uninnit_memory = nullptr;
>
> As you can see your approach is taking linearly more
> recourses and is harder to manage as it scales with the
> number of effected fields while my approach is staying
> constant.

Thanks for highlighting this with the C example. I see now what you mean by
how my idea should have been written.

> You got how null and objects work slightly wrong
> resulting in some wrong assumptions.
>
> Remember all object variables in Java are just memory
> addresses (it's a bit more complicated but the details
> don't matter here). If you assign the object to the final
> field/ variable all you are doing is taking the memory
> address of the thing on the right and storing it in the
> field. The field itself also has an address so it would
> be possible to change it afterwards but saying the field
> is final makes that "illegal".

Hmmmmm, I'm not fully following what you mean here though. It sounds like
you are saying 2 addresses, one for the variable and one for the newly
allocated object? Or am I misreading that? That may also contribute to me
not understanding that first sentence of this quote either.

> Hope this cleared up some things.
>
> But don't underestimate the effort to implement it. It's
> likely to much effort in both approaches.

It definitely did, thank you very much.

And yes, I see that the level of effort for this is going to be
significant. But I still feel like this is something within reach -- enough
so that it might be worth doing.

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/20230710/baa2ff62/attachment.htm>