<div dir="ltr">On Tue, Mar 4, 2014 at 2:38 AM, Remi Forax <span dir="ltr"><<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div>

It seems like the JVM spec gets it right - i.e., you can do (mostly) whatever you want prior to super()/this() as long as it doesn't try to make use of an uninitialized 'this', and no uninitialized 'this' can escape. It seems reasonable to want the JLS to more closely mirror this sensible stance.<br>



<br>
I must be missing something...<br>
</div></blockquote>
<br>
The rules of Java the language are less permissive than the rules of the JVM regarding uninitialized instance, that's true.<br>
But at least, the Java rules is simple to understand to anyone. Adding complexity here will not worth it and as Brian mention,<br>
you can still call a static method inside this() or super().<br></blockquote><div><br></div><div>I don't see how any complexity would be added (that is, for the programmer). What's being added is flexibility. If someone wants to continue to make super()/this() the first line of every constructor, they can happily continue do so.<br>


</div><div><br></div><div>This proposal is like the change in Java8 allowing variables used in anonymous inner classes to no longer be required to be 'final'. Both changes are simply relaxing an unnecessary source code restriction. I'd even argue this proposal has much more unambiguous semantics than that change does.<br>

<br></div><div>And those semantics are not anything new really. Think of the restrictions that apply to a final field: you must set it exactly once, and you must set it before you use it. This proposal would have the same restriction on 'this': you must initialize it exactly once, and you must initialize it before you use it.<br>


</div><br><div>By the way, your suggested workaround is missing something: the only workaround (as Brian mentioned) is not not use a constructor at all, replacing it with a static factory method. Otherwise there's no way to avoid e.g. redundant calculation without changing from constructor-based creation to factory-method-based creation.<br>

<br>In any case, I don't see how the existence of an imperfect workaround makes the proposal any less correct (at least in theory).<br>
</div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    *Idea #5: Allow enum types to have generic type parameters*<div><br>
    Another frequent suggestion.  I agree it would have been better if<br>
    it were done this way initially, and the cost would have been<br>
    low.  The cost of doing this now in a binary-compatible way would<br>
    be higher.<br>
<br>
<br>
Ah, I didn't realize there was a binary compatibility problem here. What specifically is the problem?<br>
</div></blockquote>
<br>
<br>
There is another problem. You don't want an enum in your example.<br>
You want some properties of an enum but not others. An enum in Java is not only a type of a serie of values,<br>
it's a serie of values with a name, a unique number, a common type and a way to get an array of all these values (with Foo.values()).<br>
<br>
In your example, you don't want a common type and if an enum type is a generic type values() will return array of wildcard making values() (and valueOf) useless from the typing point of view. It seems you want only one part of the enum and not the other, so an enum is the wrong language construction for your problem.<br>

</blockquote><div><br></div><div>Not sure what you mean by "You don't want an enum in your example" and I don't really understand your counter-argument. Why do you say I don't want a common type? What part of an enum are you saying I don't really want?<br>

<br></div><div>Of course values() will return array of Primitive<?>. That's not useless, and certainly no more useless than array of Primitive (non-generic) which is all you get with the current enum.<br><br></div>

<div>Also, nobody has yet explained what the binary compatibility problem is. That certainly doesn't mean there isn't one, but I just don't see it yet.<br></div><div><br></div><div>Thanks,<br></div><div>-Archie<br>

</div></div><br>-- <br><div dir="ltr">Archie L. Cobbs<br></div>
</div></div>