jon pipitone wrote:
Thomas Tempelmann wrote:
I have not looked into this deeper yet, but here's what I see happening:
I have a Class A, and a Subclass B.
Class A defines a protected property "x", while the subclass has no
such property itself.
In a method of the subclass B, I write:
super.x = something
Now, in my rather complex app, I found that the class A would not find
the property "x" assigned with the value.
But if I only make this single change:
me.x = something
Then the super class sess its property "x" changed.
How can this possibly be? To me, this looks like a bug.
Yep, I can confirm this. Here are my results.
If, in class B, you set super.x to something then methods from both A
and B cannot see x has having changed. But if, from class B, you
return super.x you do get the value set earlier (totally nuts!)
Now, if you set B.x to something then from methods in both A and B you
can get this value back, as expected. But you cannot get this value
from methods in B by referencing super.x.
It's as if super.x is an entirely different variable from A.x or B.x
and can only be referenced via super.x.
Have you created a bug report for this?
There is no bug to report. (Except maybe that 'super.x' should throw a
syntax error) The problem here appears to be a misunderstanding of
inheritance in the OOP paradigm.
Non-shared properties are members of *instances*, not classes, and
should always be referenced as instanceName.propertyName. In the case
mentioned, every instance of A and every instance of B has its own,
distinct member named 'x', each stored in a different location in
memory. If A defines a property x, and B is a subclass of A, then yes, B
does indeed have such a propery itself as subclasses 'inherit' all of
the properties of their superclasses (even the private ones, although
they cannot reference them directly)
'super' references a class, not an instance, and is for accessing
methods in the parent class that may have been overridden in the child
class. super.x should be a syntax error, but if not it is at best
undefined as it does not specify which of possibly many instance-bound x
properties in memory you wish to access. Methods of either A or B that
refer to x or me.x will be referring to the x member of the instance
upon which the method was invoked. InstanceName.x can refer to the x
property that belongs to another known instance of A or B. Self.x will
be legal only if the object to which self refers is an instance of A, B,
or a subclass of B since x is protected. Any reference to instanceName.x
by a method that is not in A, B, or a subclass of B would not be legal.
Other subclasses of A (and their subclasses) would also have instance
members named x, but methods of B and its subclasses can not reference
them directly because they are not in the same inheritance line. (check
out the 'IsA' relationship)
If the property is shared, then there is only one memory location for an
x property that is common to all instances of A and all of its
subclasses. In that case instanceOne.x, instanceTwo.x, A.x, B.x, or
super.x should all refer to the same memory location.
Make sense?
Ken
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
