<div dir="ltr"><div style="font-family:monospace" class="gmail_default"><br>Hello RedIODev,<br><br>Thank you for your response!<br><br>> The "change the variable itself afterwards" idea also is<br>> the reason you think the keyword should be at the use<br>> site.<br>> <br>> But this puts all the work and the track keeping to the<br>> runtime which now has to keep a list of what fields<br>> belong to this delayed object. Something the memory<br>> address (field) is already doing by itself in case of a<br>> valid object.<br>> <br>> So the simpler and more logical approach is to just set<br>> the field to the already prepared memory location the<br>> object will be initialized to. But mark that location so<br>> it will be treated as null if accessed through a field.<br>> This requires only 1 note for the runtime per object<br>> instead of per field. <br>> <br>> I don't know if you are familiar with C but here are the<br>> 2 approaches modeled in C:<br>> <br>> your approach:<br>> <br>> Foo* foo = null;<br>> Foo* foo2 = null;<br>> <br>> //runtime remembers fields<br>> Foo** __foo_field = &foo;<br>> Foo** __foo_field2 = &foo2;<br>> <br>> // some stuff<br>> <br>> //foo init<br>> Foo* actual_foo = malloc(sizeof(Foo));<br>> init_foo(actual_foo);<br>> <br>> // setting of every forwarded declare field<br>> *__foo_field = actual_foo;<br>> *__foo_field2 = actual_foo;<br>> <br>> // runtime forgetting now fully init fields. <br>> Foo** __foo_field = nullptr;<br>> Foo** __foo_field2 = nullptr;<br>> <br>> My approach:<br>> <br>> Foo* actual_foo = malloc(sizeof(Foo));<br>> Foo* foo = actual_foo;<br>> Foo* foo2 = actual_foo;<br>> <br>> //Runtime remembers memory as not initialized <br>> Foo* uninit_memory = actual_foo;<br>> <br>> //Some stuff<br>> <br>> //foo init<br>> init_foo(uninnit_memory);<br>> <br>> // runtime forgetting now initialized memory <br>> uninnit_memory = nullptr;<br>> <br>> As you can see your approach is taking linearly more<br>> recourses and is harder to manage as it scales with the<br>> number of effected fields while my approach is staying<br>> constant. <br><br>Thanks for highlighting this with the C example. I see now what you mean by how my idea should have been written.<br><br>> You got how null and objects work slightly wrong<br>> resulting in some wrong assumptions.<br>> <br>> Remember all object variables in Java are just memory<br>> addresses (it's a bit more complicated but the details<br>> don't matter here). If you assign the object to the final<br>> field/ variable all you are doing is taking the memory<br>> address of the thing on the right and storing it in the<br>> field. The field itself also has an address so it would<br>> be possible to change it afterwards but saying the field<br>> is final makes that "illegal". <br><br>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.<br><br>> Hope this cleared up some things.<br>> <br>> But don't underestimate the effort to implement it. It's<br>> likely to much effort in both approaches. <br><br>It definitely did, thank you very much.<br><br>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.<br><br>Thank you for your time and help!<br>David Alayachew<br></div><br></div>