why doesn't this work? final assignments and switches

[xaos]

class foo
{
final int A0,A1,A2,A3,A4;

public foo()
{
int x=0;
A0=x++;
A1=x++;
A2=x++;
A3=x++;
A4=x++;
}

int getValue(int n)
{
int v=-1;
switch(n)
{
case A0:
// compiler complains:
// constant expression required
// but isn't A0 etc constant ?
break;
caseA1:
break;
caseA2:
break;
caseA3:
break;
caseA4:
default:
}
return v;
}
}

 

[Roedy Green]

case A0:
// compiler complains:
// constant expression required
// but isn't A0 etc constant ?

switch cases want [values known at compile time. Yours are not known
until the class is instantiated.

try static final A0 = 0;

But if you are calling them A0, why not just say 0?

 

[Roedy Green]

try static final A0 = 0;

oops, one of my most common errors:


private static final int A0 = 0;

 

[xaos]

nesuth- no matter whether it is static or not - the point is to assign a
set of final int 's by using x++ and satisfying the conditions of
switch....

the final variables may be asigned statically, in the constructor or
whatever, however, it seems that the compiler only performs a very
shallow inspection of the variables in regaurd to compiling switches.

It is perfectly ok to assign the final variables A0, A1 ... in the
constructor (if they ar not static.)
and it is perfectly ok to assign them with an X++ type expression.
however the technology behind the compilation of switch statement
expects something 'easier' to assure that A0 is constant, and that it
should be unique among the cases. X++ satisifies both, as the value of
A0 will be immutable, and the series generated creates unique values.
This should be sufficient to work a switch statement - I believe.

The reason for using A0=X++; A1= X++; is that inserting variables such
as A0_1 and A0_2 between A0 and A1 won't require changing all the
values after A0 by hand.

Sure, there are work arounds, but since java offered modest developer
conveniences to sdk1.5 - how about this one which helps the "hand coder".

~SS~

 

[Christophe Vanfleteren]

nesuth- no matter whether it is static or not - the point is to assign a
set of final int 's by using x++ and satisfying the conditions of
switch....

the final variables may be asigned statically, in the constructor or
whatever, however, it seems that the compiler only performs a very
shallow inspection of the variables in regaurd to compiling switches.

It is perfectly ok to assign the final variables A0, A1 ... in the
constructor (if they ar not static.)
and it is perfectly ok to assign them with an X++ type expression.
however the technology behind the compilation of switch statement
expects something 'easier' to assure that A0 is constant, and that it
should be unique among the cases. X++ satisifies both, as the value of
A0 will be immutable, and the series generated creates unique values.
This should be sufficient to work a switch statement - I believe.

The reason for using A0=X++; A1= X++; is that inserting variables such
as A0_1 and A0_2 between A0 and A1 won't require changing all the
values after A0 by hand.

Sure, there are work arounds, but since java offered modest developer
conveniences to sdk1.5 - how about this one which helps the "hand coder".

~SS~

Please don't toppost

And what should the compiler do once a you have another constructor, that
starts with x != 0?

A switch statement is not a just another way of using if/else if/else, it is
a special construct even at the bytecode level.

 

[xaos]

Granted, A0, A1 is boring example.

lets say we have an array of names


final String names=
{
"mouse",
"cat",
"dog",
"tiger",
"whale"
};

final int
MOUSE=0,
CAT=1,
DOG=2,
TIGER=3,
WHALE=4 ;

switch (N)
{
case MOUSE: squeak();break;
case DOG: bark(); break;
case CAT: purr(); break;
case TIGER: roar() ; break;
case WHALE : spoutOutJonah(); break;
default:
}



the respective indices should be
MOUSE =0, CAT=1, DOG=2,TIGER=3, WHALE=4 and they are in some sort of
natural order (animal's size here) such that names[MOUSE] ="mouse" and
programming is sane - if you want a tiger property, use TIGER as an index.
If you want the next smaller animal than a tiger in the set, it's
animals[TIGER-1]


add to the String array, "ant", "elephant", "shrew", "sparrow" in the
appropriate places (size)

and all the int's need to be rewritten (by hand) - which i find tiresome
and deem 'should be unnecessary'


a workaround is just append the names to the array in the order of
thought, using the next available index, and use a second array of ints
to keep order.

it's curious that

final int
MOUSE=0,
CAT=MOUSE+1,
DOG=MOUSE+2;

works ok. The compiler either recognizes the pattern "final + literal"
is constant, or actually calculates MOUSE+1.

X++, or X+1 is equally simple, but since X is not final - the compiler
is confounded.

~Steve~

case A0:
// compiler complains:
// constant expression required
// but isn't A0 etc constant ?

switch cases want [values known at compile time. Yours are not known
until the class is instantiated.

try static final A0 = 0;

But if you are calling them A0, why not just say 0?

 

[Chris Uppal]

xaos wrote:

final int A0,A1,A2,A3,A4;

public foo()
{
int x=0;
A0=x++;
A1=x++;
A2=x++;
A3=x++;
A4=x++;
}

switch(n)
{
case A0:
// compiler complains:
// constant expression required
// but isn't A0 etc constant ?

In a word, no.

If you want to get that effect then you need A* to be constant valued
expressions, nothing else is allowed.

To that, first you need to initialise them explicitly and to constant valued
expressions, not by executing code (as Christope has already pointed out, there
may be other constructors that initialise them to other values). So you need:

final int A0 = 0, A1 = 1, A2 = 2, A3 = 3, etc...

Once you have that, the compiler is *required* to treat each read of the
variables as if they were replaced in the code by the corresponding integer
literals. Hence the switch statement will start working.

If you want to retain the "self numbering" property that your original code
has, then the best you can do, whilst keeping each variable initialised to a
constant valued expression, is something like:

final int A0 = 0;
final int A1 = A0+1;
final int A2 = A1+1;
// etc...

The last thing is that since these "variables" are now *really* constants, you
may as well make them static too:

static final int A0 = 0;
static final int A1 = A0+1;
static final int A2 = A1+1;
// etc...

BTW, this isn't about "how clever" the compiler is, or should be. All this is
in the JLS2 and is part of Java's specified semantics -- the compiler has no
real choice in how it implements these things.

-- chris

 

[xaos]

xaos wrote:



Please don't toppost

And what should the compiler do once a you have another constructor, that
starts with x != 0?

the condition of 'finality' will not change.
I would make the assignments outside the constructor, possibly
statically. I would make X private with no other references to X except
the X=initialValue, and the X++ assignments - if that were to help
allay the compiler's complaints.

the nature of the sequencing assures undoubtedly that there will never
be two identical cases in a switch.

A switch statement is not a just another way of using if/else if/else, it is
a special construct even at the bytecode level.

Yes indeed, it [switch] was reproduced from the alluring performance of
it's c++ parent, and according to Java In a Nutshell, "not very
java-like" but neccesary.

There is a degree of foreignness apparent in switch code, in that java
doesn't even have a 'constant' keyword but implicitly imposes the
condition as borrowed from C++.

it's odd that java's optimization depends on me doing the work, actually
typing out literals.
Well, not to bend java archetecture to my convenience. I'll write a
pluggin to work the desired initialization.


Anyway, there is either something very fundemental in the compile time
(dynamic look-ups, procedural order, etc. ) and or runtime procedure
that precludes the possibility of making a compile time evaluation of
X++ suitable to switches,
or
java's switch was contrived to fit C++'s form and X++ just won't fit the
mold.

thank's all

hi ho it's off the the salt mine...


~S~