Home arrow static arrow Java Programming [Archive] - java constructors drive me mad
Warning: Creating default object from empty value in /www/htdocs/w008deb8/wiki/components/com_staticxt/staticxt.php on line 51
Java Programming [Archive] - java constructors drive me mad
This topic has 219 replies on 15 pages.    « Previous | 1 | ... 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | Next »

Posts:2,830
Registered: 9/1/03
Re: java constructors drive me mad  
Jun 20, 2004 11:27 PM (reply 105 of 219)



 
it was already explained ... i can't see how this
argument is still continuing ?
I was already explained that most of the posters are
thinking in java. Particularly, thay cannot imagine
that memory is allocated for the whole object at once
(objects are localized in time and space). Any object
is not valid until all fields are initialized. It does
not matter in which order you do it.

If you are talking about another language then I'll leave you to it, because
im not really interested in that ... initially the question is: why can't it be
done ? i think that's been explained, if you want to write a new language,
or enhance java to allow you to set values in classes that do not, and may
never, exist, then thats fine, good luck :)

you can't set the fields of some uninitialised class
because it doesn't exist
What does not exist?

the class. it's constructor hasn't run so in theory it does not
exist., even though, someone demonstrated (lazlo ?) that you
can call a method in such a class via method overriding, its
results are strange as some variables may not have their values.

its the same effect, where can the variable go ?
nowhere. the jvm has nowhere
to put it yet, so it tells you so.

JLS == absolute thruth?

at all ! i.e. take a man who has no hands, and ask
him
to catch a ball,
You've forgot to initialize hand fields.

I didn't forget, it hasn't been done, and wont be done and initialisation
of the body.

assign the variable to the class once it exists, not
before hand ...
Class c = new Variable()?

What ?
 

Posts:835
Registered: 2/12/01
Re: java constructors drive me mad  
Jun 21, 2004 12:06 AM (reply 106 of 219)



 
initially the
question is: why can't it be
done ? i think that's been explained,
It was explained by jsalonen, the reasons are historical.

if you want to
write a new language,
or enhance java to allow you to set values in classes
that do not, and may
never, exist, then thats fine, good luck :)
I don't know which classes are you talking about.

you can't set the fields of some uninitialised
class
because it doesn't exist
What does not exist?

the class. it's constructor hasn't run so in theory it
does not
exist., even though, someone demonstrated (lazlo ?)
that you
can call a method in such a class via method
overriding, its
results are strange as some variables may not have
their values.
are you about Replay 6? I was aware about this fact long time before. It just proofs that the requirement to call super() first does not save you from using uninitialized variables. It just brings inconsistency preventing you from using initialized variables. And this bug in JLS (killer) makes me insane. The correct approach would be to initialize vars with initial values before executing constructor.


I didn't forget, it hasn't been done, and wont be done
and initialisation
of the body.
May be the phrase is in correct english but I cannot understand it.

Class c = new Variable()?
What ?
May be it is correct to tell "assign the variable to the class once it exists" in OOP but I cannot understand.
 

Posts:2,830
Registered: 9/1/03
Re: java constructors drive me mad  
Jun 21, 2004 12:20 AM (reply 107 of 219)



 
if you want to
write a new language,
or enhance java to allow you to set values in
classes
that do not, and may
never, exist, then thats fine, good luck :)
I don't know which classes are you talking about.

the subclass.

you can't set the fields of some uninitialised
class
because it doesn't exist
What does not exist?

the class. it's constructor hasn't run so in theory
it
does not
exist., even though, someone demonstrated (lazlo ?)
that you
can call a method in such a class via method
overriding, its
results are strange as some variables may not have
their values.
are you about Replay 6? I was aware about this fact
long time before. It just proofs that the requirement
to call super() first does not save you from using
uninitialized variables.

well the error you are seeing is not due to an 'uninitialised' variable,
otherwise you would only receive a problem upon reading - the error
you are seeing is that the variable does not exist yet ...

It just brings inconsistency
preventing you from using initialized variables. And
this bug in JLS (killer) makes me insane. The correct
approach would be to initialize vars with initial
values before executing constructor.

well this does happen ... they are just not populated (some of them) before
the parent constructor has completed.

I didn't forget, it hasn't been done, and wont be
done
and initialisation
of the body.
May be the phrase is in correct english but I cannot
understand it.

yes, i can't understand it either, i made a very bad typo :) I meant to say:
"I didn't forget, it hasn't been done [initialisation of hands] and won't be done until initialisation of the body is complete".

Class c = new Variable()?
What ?
May be it is correct to tell "assign the variable
to the class once it exists"
in OOP but I cannot
understand.

"Assign the value to the variable in the class", is what i meant, again a major typo :)
 

Posts:835
Registered: 2/12/01
Re: java constructors drive me mad  
Jun 21, 2004 1:21 AM (reply 108 of 219)



 
if you want to write a new language, or enhance java to allow you to set values in classes that do not, and may never, exist, then thats fine, good luck :)
the subclass.

Where did I refer derived fields of the instance under construction before they are initialized?

well the error you are seeing is not due to an 'uninitialised' variable,
otherwise you would only receive a problem upon reading - the error
you are seeing is that the variable does not exist yet ...
?

What does it mean "var does not exist?". How can you coordinate this your thesis with

well this does happen ... they are just not populated (some of them) before
the parent constructor has completed.


What do you populate in the constructor if the instance is not yet created? That is, in programming, after memory is allocated, we have an array of uninitialized fields to be populated by the constructor. If memory is not allocated we have nothing to do in the constructor.

"I didn't forget, it hasn't been done [initialisation of hands] and won't be done until initialisation of the body is complete".
So, you have a human. It has 3 fields (body, hand1, hand2). It was my first countr example to the BB's wardrobe. Will you insists that your hands were created after the body? I think you won't; thus your example is incorrect. In the nature, all the variables/fields of an object can be populated simultaneously, independently of what wich were derived and which are new to the subclass. In the nature there are no links to the class/superclass object; therefore, you cannot know which are derived attributes which are new, OK? If you want a killer example, here it is. A killer is a person (fname, sname,bdate,addr) with a new knife field. How will you construct the object? Will you add a knife to the person or person to the knife? I insist that you can fill all the fields (fname,sname,bdate,addr and knife simultaneously). Any instance is nothing more than a record of fields.
How don't you want to understand that an object is a solid/atomic collection of fields, the coupling between fields is much more strong than a java reference. That is, it is not possible to deprive of your birth date. This consideration is correlated to that where java-addicted programmers was trying to convince me that SQL table is a map of records but could not bring any example were some fields of the record are mapped to other. So, if you have hands refering to the body within your entity, you have a redundancy and violation of DB normalizarion rules, which states that fields of a record should be independent of each other. This enables simultaneous (without any particular order) initialization of the fields. Again, constructing an object you should not know which fields are derived and which are new. You may start initializing the new fields.

The disadvantages in super() to be first I see are:
-- irregulatity, in programming it is allowed to access any initialized variable;
-- java programmers loose sense of reality

 

Posts:2,830
Registered: 9/1/03
Re: java constructors drive me mad  
Jun 21, 2004 1:40 AM (reply 109 of 219)



 
if you want to write a new language, or enhance
java to allow you to set values in classes that do
not, and may never, exist, then thats fine, good luck
:)
the subclass.

Where did I refer derived fields of the instance under
construction before they are initialized?

where did i say you were referring to derived fields - you are refering to
a field in a class that is not initialised.

well the error you are seeing is not due to an
'uninitialised' variable,
otherwise you would only receive a problem upon
reading - the error
you are seeing is that the variable does not exist
yet
...
?

What does it mean "var does not exist?". How can you
coordinate this your thesis with

well this does happen ... they are just not
populated (some of them) before
the parent constructor has completed.

I have no idea what you mean here ...

What do you populate in the constructor if the
instance is not yet created? That is, in programming,
after memory is allocated, we have an array of
uninitialized fields to be populated by the
constructor. If memory is not allocated we have
nothing to do in the constructor.

huh ? the class is initialised (fields set) before the constructor is run, we agreed on this
above .......... ?

"I didn't forget, it hasn't been done
[initialisation of hands] and won't be done until
initialisation of the body is complete".

So, you have a human.

Lets not discuss this as an example, as it is not appropriate. no examples at
all, really, are required to discuss this topic ... infact i can't even remember what
I am arguing about, but im sure that discussing this example will not help :)

You
may start initializing the new fields.

You actually can't do this !!! in java, the super-class must be instantiated
for the sub-class to exist - whether you like it or not.

Consider the exception case i gave you a while back .. superclass throws exception
upon construction ... what now happens to your fields that you've set ? where did they go ?
how were they set in the first place if no super-object ever existed !?
 

Posts:37,103
Registered: 3/30/99
Re: java constructors drive me mad  
Jun 21, 2004 1:55 AM (reply 110 of 219)



 
In this case, it's clear that root is never
used before it's initialized, so why can't we do
this?

but the creation of DTMN might not even work ... when
would root be assigned ?
after the call completes ? no, not possible ... before
the call completes then, but
then what has happened ? we've assigned some value to
some class that isn't
even created ... ! surely you can't think this is a
good thing, right ?

How is this any different than if the creation of DTMN fails if the assignment is part of root's declaration as per the existing legal syntax?

Note: For the record, I'm glad that we're not allowed to do what valjok proposes. I'm just saying that at first glance it appears it might be workable. I've seen nothing that proves either that it is or that it isn't workable, but I suspect that, even if it's workable in theory, in practice it could lead to some very subtle, difficult to find logic errors. I think the predicability afforded by the existing model has far more value than any coding convenience that might be added by allowing access to child members before super is constructed.

i.e. consider if the 'root' is assigned before the
call would complete (as it would
if it worked today) ... if the parent class throws
some exception during its construction,
... we're in trouble, as we've put a value in a
non-existent class.

Not sure what you're saying here. There's one object--one block of memory--and that's the instance of the child class. It includes all the fields of super, super's super, etc. The location for the root reference exists before any ctors are called.

From the JLS:

Whenever a new class instance is created, memory space is allocated for it with room for all the instance variables declared in the class type and all the instance variables declared in each superclass of the class type, including all the instance variables that may be hidden (�8.3).

This is in 12.5, preceding the constructor steps.

"Non existent class"? You mean non-existant object, I assume.

Your quote above (and other arguments I've seen here) suggest a misconception that there are separate objects created--one for super and one for child, and that the space to store the child object isn't allocated until after the super is done being constructed. This is incorrect. My apologies if I misunderstood and you're not in fact under that misconception.
 

Posts:37,103
Registered: 3/30/99
Re: java constructors drive me mad  
Jun 21, 2004 2:05 AM (reply 111 of 219)



 
In the first example I pass an initialized
ref
to the super().

No, you do not. Why? Because local fields are not
initialized before the call to super()

I believe valjok is saying one should be able to do like he did in his first example, which would allow you to initialize sub's field before super's construction is complete. It sounds like he understands that the JLS says he can't do that, but wonders why not. If the restriction that "super must be constructed before referencing sub's fields" were relaxed, he could do that, and it would be an initialized field.

Again, I don't support this position--merely trying to clarify it a bit.
 

Posts:205
Registered: 6/15/04
Re: java constructors drive me mad  
Jun 21, 2004 2:05 AM (reply 112 of 219)



 
You see, we just keep swapping about from Java specific to programming in general.

This is the reason for confusion.

Yes, the original post has been answered and explained quite sufficiently, but, I think valjok is trying to take the discussion further and determine why those guys at Sun decided to implement Java in such a manner. But the problem arises when s/he cites Java examples to substantiate his theory -this causes problems because there are no Java examples to substantiate such.

If you don't beleive me (I insult java-minded programmers by not thinking in java), consider post 60 by jverd

I'm sorry, but I do not see your view being corroberated in that post. -and I still don't see any apologies for your rudeness, which indicates (to me at least) that you are in fact a very rude person, who does not like their ideas to be questioned.
 

Posts:37,103
Registered: 3/30/99
Re: java constructors drive me mad  
Jun 21, 2004 2:08 AM (reply 113 of 219)



 
In the first example I pass an initialized
ref
to the super().

No, you do not. Why? Because local fields are not
initialized before the call to super()

If you don't beleive me (I insult java-minded
programmers by not thinking in java), consider post 60
by jverd.

Can you lay off the insults here? I don't appreciate being called in as support for your position when a) I don't agree with it and b) you're being rude, insulting, and condescending.
 

Posts:37,103
Registered: 3/30/99
Re: java constructors drive me mad  
Jun 21, 2004 2:16 AM (reply 114 of 219)



 

it was already explained ... i can't see how this
argument is still continuing ?
I was already explained that most of the posters are
thinking in java. Particularly, thay cannot imagine
that memory is allocated for the whole object at once
(objects are localized in time and space). Any object
is not valid until all fields are initialized. It does
not matter in which order you do it.

It's true that memory is allocated for the whole object at once, so the argument that "there's no place to put it" doesn't hold water.

However, that by itself isn't sufficient grounds on which to claim the order of field initialization doesn't matter. It's possible that a subclass field could rely on super being initialized in order to get a valid value, for instance. Or it could simply be that compilers or debugging or something would be unreasonably complex if you relaxed the restriction that super is totally constructed before touching sub. In this case there's not necessarily a required order of variable initialization as a first principle--rather it's a side effect of the more general rule.

Or it could be that the rule is overly restrictive and could be relaxed for things like valjok's very first code example in this thread.

I haven't seen anything definite one way or the other, but I'm inclined to think the existing restriction is a good one.



you can't set the fields of some uninitialised class
because it doesn't exist
What does not exist?

its the same effect, where can the variable go ?
nowhere. the jvm has nowhere
to put it yet, so it tells you so.

JLS == absolute thruth?

at all ! i.e. take a man who has no hands, and ask
him
to catch a ball,
You've forgot to initialize hand fields.

assign the variable to the class once it exists, not
before hand ...
Class c = new Variable()?
 

Posts:2,830
Registered: 9/1/03
Re: java constructors drive me mad  
Jun 21, 2004 2:16 AM (reply 115 of 219)



 
In this case, it's clear that root is never
used before it's initialized, so why can't we do
this?

but the creation of DTMN might not even work ...
when
would root be assigned ?
after the call completes ? no, not possible ...
before
the call completes then, but
then what has happened ? we've assigned some value
to
some class that isn't
even created ... ! surely you can't think this is a
good thing, right ?

How is this any different than if the creation of DTMN
fails if the assignment is part of root's declaration
as per the existing legal syntax?

Lost me here ...

in a statement like this:
foo( (b = c()) )
isn't it a requirement that b is assigned for foo to execute ?

in yuor case, i.e. normal failure:
b = c()
if the operation to get b fails, be isn't assigned ... in our situation we
need 'b' to be assigned to execute foo, but this can't be possible
if c() failed, so if c() has failed we cannot possibly be inside the "foo"
method given my first statement .. can we ?

i.e. consider if the 'root' is assigned before the
call would complete (as it would
if it worked today) ... if the parent class throws
some exception during its construction,
... we're in trouble, as we've put a value in a
non-existent class.

Not sure what you're saying here. There's one
object--one block of memory--and that's the instance
of the child class. It includes all the fields of
super, super's super, etc. The location for the root
reference exists before any ctors are called.

From the JLS:

Whenever a new class instance is created, memory
space is allocated for it with room for all the
instance variables declared in the class type and all
the instance variables declared in each superclass of
the class type, including all the instance variables
that may be hidden (�8.3).

yes ... okay, sure, space is allocated, but the subclass isn't initialised (fully),
this is what i mean by 'non-existant'..

This is in 12.5, preceding the constructor steps.

"Non existent class"? You mean non-existant object, I
assume.

Yes.

Your quote above (and other arguments I've seen here)
suggest a misconception that there are separate
objects created--one for super and one for child, and
that the space to store the child object isn't
allocated until after the super is done being
constructed. This is incorrect. My apologies if I
misunderstood and you're not in fact under that
misconception.

well i consder more objects to be created as in more objects are
initialised, i.e all your super-classes constructors are run, right ?
 

Posts:37,103
Registered: 3/30/99
Re: java constructors drive me mad  
Jun 21, 2004 2:28 AM (reply 116 of 219)



 
How is this any different than if the creation of
DTMN
fails if the assignment is part of root's
declaration
as per the existing legal syntax?

Lost me here ...

in a statement like this:
foo( (b = c()) )
isn't it a requirement that b is assigned for
foo to execute ?

Yeah. If b=c() throws an exception the then the statement throws that exception and foo is never executed.


in yuor case, i.e. normal failure:
b = c()
if the operation to get b fails, be isn't assigned ...
in our situation we
need 'b' to be assigned to execute foo, but this
can't be possible
if c() failed, so if c() has failed we cannot possibly
be inside the "foo"
method given my first statement .. can we ?

You lost me. Valjok's original example:
class Tree extends JTree {    private final DefaultMutableTreeNode root;    Tree() {        super(new DefaultTreeModel(root = new DefaultMutableTreeNode("Download Manager")));    }


So if new DMTN("") throws an exception, then root's not assigned, new DTM() isn't called, super isn't called, and Tree's ctor throws the exception. How is that any different than this?
super(someOtherMethodThatDoesntReferToAChildMemberButThrowsAnException()) 


i.e. consider if the 'root' is assigned before the
call would complete (as it would
if it worked today) ... if the parent class throws
some exception during its construction,
... we're in trouble, as we've put a value in a
non-existent class.

Not sure what you're saying here. There's one
object--one block of memory--and that's the instance
of the child class. It includes all the fields of
super, super's super, etc. The location for the root
reference exists before any ctors are called.

From the JLS:

Whenever a new class instance is created, memory
space is allocated for it with room for all the
instance variables declared in the class type and
all
the instance variables declared in each superclass
of
the class type, including all the instance variables
that may be hidden (�8.3).

yes ... okay, sure, space is allocated, but the
subclass isn't initialised (fully),
this is what i mean by 'non-existant'..

Okay, but how is it relevant? If the "root=" part throws an exception, the whole thing throws the exception, just like if any other method that were called as an arg to super() did.

well i consder more objects to be created as in more
objects are
initialised, i.e all your super-classes constructors
are run, right ?

Okay, not sure where you're going with this either.
 

Posts:205
Registered: 6/15/04
Re: java constructors drive me mad  
Jun 21, 2004 2:28 AM (reply 117 of 219)



 

Your quote above (and other arguments I've seen here)
suggest a misconception that there are separate
objects created--one for super and one for child, and
that the space to store the child object isn't
allocated until after the super is done being
constructed. This is incorrect. My apologies if I
misunderstood and you're not in fact under that
misconception.

jverd, you are right. I hold my hands up as one of the main perpetraitors.

This was a bad thing to write ...

Now, if object2 sub-classes object1, then first of all, enough memory must be allocated to hold the v-table for object1, and because (generally) object2 has further methods/fields etc, a further chunk of memory has to be allocated to contain the v-table for these too, so to

and my intention was not to mislead with the notion that memory is allocated piecemeal, but instead to highlight that a sub-class, has the same structure as its parent class, with some extra stuff appended.

this was also a VERY terrible thing to write ..

in order to allocate enough memory for the instantiation of Obj4, one must first initialize Obj3, and in order to allocate enough memory for the instantiation of Obj3, one must first initialize Obj2, and in order to allocate enough memory for the instantiation of Obj2, one must first initialize Obj1. (maybe I'm proving my huge misconcepts about object instances in Java)

and again, my intention was not to say that memory is calculated on the fly (at the point of object instantiation), although it does read that way. I guess I should have really written that last phrase thus :

in order to instantiate Obj4, one must first initialize the fields of Obj3, and in order to initialize the fields of Obj3, one must first initialize the fields of Obj2, and in order to initialize the fields of Obj2, one must first initialize the fields of Obj1.

I hope that leaves me deserving of a pardon and complete exoneration :o)
 

Posts:2,830
Registered: 9/1/03
Re: java constructors drive me mad  
Jun 21, 2004 2:35 AM (reply 118 of 219)



 
in yuor case, i.e. normal failure:
b = c()
if the operation to get b fails, be isn't assigned
...
in our situation we
need 'b' to be assigned to execute foo, but this
can't be possible
if c() failed, so if c() has failed we cannot
possibly
be inside the "foo"
method given my first statement .. can we ?

You lost me. Valjok's original example:
class Tree extends JTree {private final DefaultMutableTreeNode root;Tree() {super(new DefaultTreeModel(root = newDefaultMutableTreeNode("Download Manager")));}


So if new DMTN("") throws an exception,

but jverd, root must be assigned for the new DMTN call to complete ...


well i consder more objects to be created as in more
objects are
initialised, i.e all your super-classes constructors
are run, right ?

Okay, not sure where you're going with this either.

nowhere, lets just forget about this bit :) all I mean is that the subclasses
initialisation is not run, so you can't set it's fields... this is my point, however
laszlo's code in 6 breaks it, although there may be some special things
that happen there, i haven't thought about that code much.
 

Posts:37,103
Registered: 3/30/99
Re: java constructors drive me mad  
Jun 21, 2004 2:41 AM (reply 119 of 219)



 
You lost me. Valjok's original example:
class Tree extends JTree {private final DefaultMutableTreeNode root;Tree() {super(new DefaultTreeModel(root = newDefaultMutableTreeNode("Download Manager")));}


So if new DMTN("") throws an exception,

but jverd, root must be assigned for the new
DMTN call to complete ...

Huh? Other way around, not? new DMTN must complete in order to assign to root. If DMTN's ctor throws an exception, root is not assigned, new DTM is never called, super is never called, Tree's ctor throws the exception.

I don't see what's special about assigning to root here--it seems not different than if any other method call as an arg to super() threw the exception.

But I'm content to drop it if you are.
 
This topic has 219 replies on 15 pages.    « Previous | 1 | ... 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | Next »