At 11:05 AM 7/16/99 +0200, Kontorotsui wrote:
>
>On 14-Jul-99 Michael Sinz wrote:
>> The reason is that until the constructor is called, no instance data
>> can be used.  Note that you did not make this static final but rather
>> final.  This means there must be actual instance data to access this
>> variable and that does not exist until super() returns since until
>> that point in time *no* instance data space was allocated (let alone
>> initialized)
>
>Ok, but it doesn't work either with static final. 

Then there is a bug in javac... http://java.sun.com/cgi-bin/bugreport.cgi

Jikes will accept the following code:
class aSuperClass {
        aSuperClass(int i) {
                System.out.println("aSupperClass("+i+")");
        }
}
class aClass extends aSuperClass {
        static final int v = 1;
        aClass() {
                super(v);
                System.out.println("aClass()");
        }
}
class mainline {
        public static void main(String[] a) {
                new aClass();
        }
}

and the result of a run is:
aSupperClass(1)
aClass()

>> Actually, unless it is statis final it is not a real constant.
>> And even static final is a variable, it just happens to be unchangeable.
>
>Ok, then what is missing is a real constant in Java, something useful only
for
>the code writer and that can be automatically substituted by the
preprocessor.

Actually with the way class files are designed there either really is no
such thing, or everything is like that. (it depends on your POV.) I tend
to view it as "static final is #DEFINE" when it comes to primitives; objects
are different! For example, the aClass above disassembles into :

Method aClass()
   0 aload_0
   1 iconst_1
   2 invokespecial #15 <Method aSuperClass(int)>
   5 getstatic #21 <Field java.io.PrintStream out>
   8 ldc #23 <String "aClass()">
  10 invokevirtual #29 <Method void println(java.lang.String)>
  13 return

iconst_1 is a bytecode special item because numbers like 0 and 1 occur SO
often in code that they have special bytecode representation; there is one
for each of -1..5. If I make that 1024 instead...

Method aClass()
   0 aload_0
   1 sipush 1024
   4 invokespecial #15 <Method aSuperClass(int)>
   7 getstatic #21 <Field java.io.PrintStream out>
  10 ldc #23 <String "aClass()">
  12 invokevirtual #29 <Method void println(java.lang.String)>
  15 return

As you can see the value 1024 is "hard coded" into the bytecode just like
you want.

[...]
>As you see the lack of a real constant forces me to manually put 15 in the
>constructor and in the for upper bound. This is bad because if one day I want
>the 15 to be a 18, I'll have to remember to change it also in the for.

Make it "static final int MYCONST=18;" and get a better compiler.

Another option is to put it in another class... for example a project I
work on has a class CONST in each package which is final and contains
nothing but static finals fields; then you code super(CONST.someproperty);
In theory these are all package wide constants... and there are similar
classes in all packages, including superpackages.

>> BTW - please reduce the size of your signature.  It is cute but well beyond
>> the requirement to identify yourself.
>
>I'm trying to set up rules to change it depending on the mailing list I'm
>writing to. Meanwhile I'll manually reduce it, be patient if I sometimes I
>forget to do it.

You mean there are actually lists where a huge ascii art sig is
appreciated? ;)
  cabbey at home dot net <*> http://members.home.net/cabbey
           I want a binary interface to the brain!
Today's opto-mechanical digital interfaces are just too slow!


----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to