Jason K. (AC)
Hansjoachim Vonhortenschiem wrote:... there is some ParentCon object that exists somewhere as a result of a call to the ChildCon constructor and this object is somehow "tied" to the ChildCon object.......? ...
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
marc weber wrote:
Hansjoachim Vonhortenschiem wrote:... there is some ParentCon object that exists somewhere as a result of a call to the ChildCon constructor and this object is somehow "tied" to the ChildCon object.......? ...
The ChildCon object IS-A ParentCon object.
As your output should demonstrate, a ParentCon constructor executes (i.e., creates an object) whenever you create an instance of ChildCon. A ParentCon object is created, and then that object is extended to become a ChildCon.
Hansjoachim Vonhortenschiem wrote:
marc weber wrote:
Hansjoachim Vonhortenschiem wrote:... there is some ParentCon object that exists somewhere as a result of a call to the ChildCon constructor and this object is somehow "tied" to the ChildCon object.......? ...
The ChildCon object IS-A ParentCon object.
As your output should demonstrate, a ParentCon constructor executes (i.e., creates an object) whenever you create an instance of ChildCon. A ParentCon object is created, and then that object is extended to become a ChildCon.
Thanks for the reply... but, could someone explain how private members of the superclass are handled in a situation like this ???
Are they initialized as a result of constructor chaining initiated by a subclass constructor?
Are they part of the "end" object, even though declared as private?
If, being private means "not inheritable", then how is it I can access them ?
Basically, I need the play by play of what actually happens behind the scene....
Thanks in advance
Hansjoachim Vonhortenschiem wrote:I think I may have the answer.....
Due to constructor chaining, the final object is a superset of all parent class members, including those members declared as private. However, because private members are not inherited, those private members that are included in the superset created by the class that initiated the instance with a call to new(), will be unaccessible by this final object. That is, unless there is also in this superset some inheritable accessor method to retrieve the private members......
Sound about right ?
What would really be nice is if there were some way to see what the final object consisted of, what it could access and what it could not.
For example, if ClassC extends ClassB and ClassB extends ClassA.....
if you say, ClassC myobj = new ClassC();
what would the picture of the actual object look like ?
what, in other words, would it consist of ?
Hansjoachim Vonhortenschiem wrote:I think I may have the answer.....
Due to constructor chaining, the final object is a superset of all parent class members, including those members declared as private. However, because private members are not inherited, those private members that are included in the superset created by the class that initiated the instance with a call to new(), will be unaccessible by this final object. That is, unless there is also in this superset some inheritable accessor method to retrieve the private members......
Sound about right ? ...
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
Just use intellisense, or look at an object view in the IDE you are using.
Hansjoachim Vonhortenschiem wrote:
Just use intellisense, or look at an object view in the IDE you are using.
if intellisense is the new cool guy way of saying intelligence, then I'm afraid I'm in short supply.
as for and IDE, I use notepad and the command prompt.
but thanks for a reason to use an IDE : )
Hansjoachim Vonhortenschiem wrote:
if intellisense is the new cool guy way of saying intelligence, then I'm afraid I'm in short supply.
Henry Wong wrote:
Hansjoachim Vonhortenschiem wrote:
if intellisense is the new cool guy way of saying intelligence, then I'm afraid I'm in short supply.
Intellisense is the name of the help system for Visual Studios. And Visual Studios is not a common IDE for Java, as Microsoft is more focused on .NET.
Henry
Hansjoachim Vonhortenschiem wrote:So, in my minds eye, I can envision an object consisting of members that are part of that objects blueprint (class), members that are inherited from the parents blueprint(thereby becoming part of the childs blueprint), and those members of the parents blueprint that, though part of the child object, are not part of the childs blueprint. These last members still occupy a space in memory and are accessible via parent provided accessor methods.
The upside is that you can have a unique instance of a parents private instance variable to compliment a child object (assuming you have a way to access it).
The downside is if the same unique instance of a parents instance varaible is hugh(!) in memory and you have no use for it whatever.
It just seems hard to believe that Java-Authors would allow such a system in which memory could be wasted in such a way......
Jason K. (AC)
Hansjoachim Vonhortenschiem wrote:... The downside is if the same unique instance of a parents instance varaible is hugh(!) in memory and you have no use for it whatever.
It just seems hard to believe that Java-Authors would allow such a system in which memory could be wasted in such a way...
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
Hansjoachim Vonhortenschiem wrote:The downside is if the same unique instance of a parents instance varaible is hugh(!) in memory and you have no use for it whatever.
It just seems hard to believe that Java-Authors would allow such a system in which memory could be wasted in such a way......
Assume the parent class has a private instance variable "Rock and Roll" ...... this is a hugh variable !
Now assume the child class has an instance variable "Bruce Springsteen" .... I hope you see where I'm going with this...?
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |