Hi,
Gav schrieb:
> I've seen an example like this:
>
[quoted text clipped - 10 lines]
> How come that memers arre initialized in their declaration? Is it a
> JButton strageness? I'm a little confused.
What excatly do you mean? Members are AFAIK the class' methods. On the
other hand you have fields - the variables. I think you mixed up the names.
What your examle code does is defining the class "Foo" with the two
fields "one" and "two, both of type JButton. Both fields are initialized
with an instance of JButton (Foo#one lables "one" and Foo#two labels
"two"). Then follows the class' constructor.
That's pretty normal Java to me. You can initialize a field where it is
definied or you can leaf that. Object types defaultly initialize with
null, number value types (int, long, double, ...) with 0 and boolean
with false. However, I think it's better to set a defined initialization
value for fields to prevent predictable programm behaviour.
> Thanks in advance
>
> GAv
hth,
Tobi
Gav - 14 May 2006 22:25 GMT
> Hi,
>
[quoted text clipped - 15 lines]
> What excatly do you mean? Members are AFAIK the class' methods. On the
> other hand you have fields - the variables. I think you mixed up the names.
YEs, sorry. Of course I meant fields.
> That's pretty normal Java to me. You can initialize a field where it is
> definied or you can leaf that. Object types defaultly initialize with
> null, number value types (int, long, double, ...) with 0 and boolean
> with false. However, I think it's better to set a defined initialization
> value for fields to prevent predictable programm behaviour.
Shouldn't this things be done in class constructor?
Thanks again,
Gav
Bjorn Abelli - 14 May 2006 23:10 GMT
[snip]
>>> Class Foo {
>>> JButton one = new Jbutton("one");
[quoted text clipped - 4 lines]
>>> }
>>> }
[snip]
> Shouldn't this things be done in class constructor?
Why "should" they?
There are several possible places where instance fields can be initialized,
and where to initialize them is most of the time a question of taste,
personal preferences and workshop standards (which can differ between
firms).
Some want to see all instance fields initialized at one place, the
constructor, others don't want to clutter up the constructor with
initializations that can be done at the point of declaration.
It would be worse if they initialized them at the declaration *and* assigned
values to them in the constructor.
// Bjorn A
Jeffrey Schwab - 15 May 2006 13:42 GMT
> Gav schrieb:
>> I've seen an example like this:
[quoted text clipped - 10 lines]
>> How come that memers arre initialized in their declaration? Is it a
>> JButton strageness? I'm a little confused.
This is a feature of the Java language. It is as though the
initialization code were inserted automatically at the beginning of
every constructor. You can do this with any member variables. You also
can provide initializers for static members right where they are
defined, and the initialization code will be run when the class is loaded.
> What excatly do you mean? Members are AFAIK the class' methods. On the
> other hand you have fields - the variables. I think you mixed up the names.
Both fields and methods are members in Java.
Tobias Schröer - 15 May 2006 15:53 GMT
Hi,
Jeffrey Schwab schrieb:
>> Gav schrieb:
>>
[quoted text clipped - 15 lines]
> initialization code were inserted automatically at the beginning of
> every constructor.
Right. If you follow the call sequence with a debugger, it looks like this:
- call super constructor and initialize super type
- step through field declarations (and assignments)
- execute rest of constructor
> You can do this with any member variables. You also
> can provide initializers for static members right where they are
> defined, and the initialization code will be run when the class is loaded.
That's how constants (static final int CONST_INT = 1;) are typically
initialized. Though, you should be able to set their values in the
static initializer, too. But that would be rather confusing, regarding
the extra code you'll have to write.
>> What excatly do you mean? Members are AFAIK the class' methods. On the
>> other hand you have fields - the variables. I think you mixed up the
>> names.
>
> Both fields and methods are members in Java.
That's right. It seems that *I* mixed up the terms a bit :(
Tobi
Gav - 15 May 2006 17:05 GMT
> Hi,
[...]
Thanks all for the answers, now it's clearer.
Gav