<div dir="ltr"><div style="font-family:monospace" class="gmail_default"><br>Hello RedIODev,<br><br>Thank you for your response!<br><br>> I see you though of it as a compile time thing. But like<br>> you also mentioned it would be difficult for the compiler<br>> to prove that no access occurs before initialization<br>> severely limiting the usefulness.<br><br>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.<br><br>> Also the things with for example instanceof and<br>> synchronization are real questions as they primary<br>> operate on identity and don't use the (garbage) data of a<br>> half initialized object.<br>> <br>> Like:<br>> <br>> Foo foo = __uninitialized;<br>> boolean b = foo instanceof Foo //true or false <br>> syncronized(foo) { //works or not? <br>> <br>> } <br>> foo = new Foo();<br><br>Good point. Let me correct myself then.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>> Also in terms of value objects and primitives it doesn't<br>> really work at all since they by definition do not have<br>> identity (in Java) so since they cannot be referenced at<br>> all they can't ever be in this uninitialized state.<br>> <br>> Overall cyclical REFERENCE structures don't make sense or<br>> work in datatypes without identity. <br><br>100% agreed.<br><br>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.<br><br>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.<br><br>> The only big obstacle I see is that it's probably not<br>> worth the cost of implementating. The private field or id<br>> approach both work and solve the problem hence this is<br>> merely a convenience feature, even though the concept<br>> might allow unforeseen possibilities not obvious right<br>> now. If other problems are found that would be solved<br>> with it it might become viable to implement. <br><br>I hear you.<br><br>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.<br><br>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).<br><br>Thank you for your time and help!<br>David Alayachew<br></div><br></div>