Re: evum constructor gotcha
Roedy Green wrote:
In a regular class, statics are initialised before any instance
variables. The enum constants are a sort of implied static
initialisation.
That is true. The JLS explicates this in ?8.9.
E.g.,
public enum Foo
{
ROY, GRAHAM, BIV;
}
is roughly equivalent to
public final class Foo extends Enum <Foo>
{
public static final Foo ROY = new Foo( "ROY" );
public static final Foo GRAHAM = new Foo( "GRAHAM" );
public static final Foo BIV = new Foo( "BIV" );
// all other static initialization occurs here
private final String name;
// any instance final variable initialized here will not
// have any knowledge of the later static inits
// but the constructor can see the instance variables
private Foo( String name )
{
this.name = name;
}
// toString(), name(), etc.
}
What if the language had been defined so the enum constants were
created (i.e. their constructors run) after the other static
initialisation?
The disadvantage is statics could not refer to enum constants.
So what if you had allowed two sets of static inits, one before the
enum definitions, and one after. In other words, allow the programmer
to determine the order of initialisation. Let him figure out how best
to avoid forward references.
That's what you sort of get manually with Patricia's suggestion of a static
initializer block that goes back and fixes up what a pre-init would have done.
IOW, Java does indeed provide a mechanism to work around the restrictions on
init order.
As Eric explained, fixing the order avoids certain problems with the approach
that you suggest. Sure, it's a compromise, but given the ability to do what
you need to without the more complicated implementation, it amounts to a
difference that makes no difference.
All right, you have to add a dozen or so lines of code. C'est la vie.
Did you read the "Discussion" block in the JLS that goes into why they chose
not to go down the route you suggest? It may not seem like a complete
explanations, though I do find it quite indicative. It does point up the
sorts of problems we'd have otherwise - then you'd be posting about the tricky
convolutions of circular references in enum and calling that "Mickey Mouse".
Mike Schilling wrote:
It's a bit unfortunate that the implementation of enums
is showing through, but c'est la vie.
--
Lew