I have created a changeset in which a class is created with an iVar, methods added that reference that iVar, and finally the class definition is changed to remove the iVar. Newly created instances of the class behave as though the iVar is still present.
Furthermore, when I add a new subclass that has an iVar of the same name, the class compiles OK (if the superclass had explicitly defined the iVar, I would not have been able to define it in the subclass). However, different slots are being accessed by superclass methods and subclass methods. In the following code (file in the attached changeset first):
inst := ClassThatUsedToHaveAVariable new. inst add: 'string'. inst contents.
subInst := ClassThatUsedToHaveAVariableSubclass new. subInst add: 'string2'. subInst subAdd: 'string3'. subInst contents. subInst subContents.
'subInst contents' and 'subInst subContents' do not give the same result. However, if the 'collection' variable is deleted from the subclass definition, they do answer the same result.
What exactly are the semantics here? It seems like this could possibly cause some problems.
Thanks, Josh
When removing the variable from the superclass, "collection" got transferred as a binding to Undeclared which makes it behave like a class variable. Therefore, superclass and subclass have different "meanings" when you refer to the name collection (superclass thinks it's a "class var", subclass thinks it's an iVar).
Cheers, - Andreas
Josh Gargus wrote:
I have created a changeset in which a class is created with an iVar, methods added that reference that iVar, and finally the class definition is changed to remove the iVar. Newly created instances of the class behave as though the iVar is still present.
Furthermore, when I add a new subclass that has an iVar of the same name, the class compiles OK (if the superclass had explicitly defined the iVar, I would not have been able to define it in the subclass). However, different slots are being accessed by superclass methods and subclass methods. In the following code (file in the attached changeset first):
inst := ClassThatUsedToHaveAVariable new. inst add: 'string'. inst contents.
subInst := ClassThatUsedToHaveAVariableSubclass new. subInst add: 'string2'. subInst subAdd: 'string3'. subInst contents. subInst subContents.
'subInst contents' and 'subInst subContents' do not give the same result. However, if the 'collection' variable is deleted from the subclass definition, they do answer the same result.
What exactly are the semantics here? It seems like this could possibly cause some problems.
Thanks, Josh
OK that makes sense. Definitely something to avoid doing.
Josh
On Feb 1, 2006, at 12:08 PM, Andreas Raab wrote:
When removing the variable from the superclass, "collection" got transferred as a binding to Undeclared which makes it behave like a class variable. Therefore, superclass and subclass have different "meanings" when you refer to the name collection (superclass thinks it's a "class var", subclass thinks it's an iVar).
Cheers,
- Andreas
Josh Gargus wrote:
I have created a changeset in which a class is created with an iVar, methods added that reference that iVar, and finally the class definition is changed to remove the iVar. Newly created instances of the class behave as though the iVar is still present. Furthermore, when I add a new subclass that has an iVar of the same name, the class compiles OK (if the superclass had explicitly defined the iVar, I would not have been able to define it in the subclass). However, different slots are being accessed by superclass methods and subclass methods. In the following code (file in the attached changeset first): inst := ClassThatUsedToHaveAVariable new. inst add: 'string'. inst contents. subInst := ClassThatUsedToHaveAVariableSubclass new. subInst add: 'string2'. subInst subAdd: 'string3'. subInst contents. subInst subContents. 'subInst contents' and 'subInst subContents' do not give the same result. However, if the 'collection' variable is deleted from the subclass definition, they do answer the same result. What exactly are the semantics here? It seems like this could possibly cause some problems. Thanks, Josh
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Josh Gargus