Problem with nil superclass in vw7.4.1
Locked
 
|
Hi, If I define this class in a vanilla 7.4.1 image (with a NIL superclass): Smalltalk
defineClass: #TestRoot superclass:
nil indexedType:
#none private:
false instanceVariableNames:
'' classInstanceVariableNames:
'' imports:
'' category:
'OldBrowsers' and I print the following expression: Class
rootsOfTheWorld I get: OrderedCollection
(TestRoot Object) If I then add an instance variable to TestRoot Smalltalk defineClass: #TestRoot superclass:
nil indexedType:
#none private:
false instanceVariableNames:
'test ' classInstanceVariableNames:
'' imports:
'' category:
'OldBrowsers' And I print: Class
rootsOfTheWorld I get: OrderedCollection
(Object) The class TestRoot is no longer there! Removing the instance
variable or adding it again doesn’t help. One of the consequences of this
is that finding senders or implementors of methods never looks in the hierarchy
of the class TestRoot which can be annoying. The same happens in a vw7.5 image.
I don’t know what other problems may come from this but it doesn’t
sound healthy. Is there a fix for this? Thanks, Mark |
Re: Problem with nil superclass in vw7.4.1
|
|
Hmm, that definitely doesn't seem healthy. Created AR
53828.
At 06:39 AM 2/6/2008, Mark Plas wrote: Hi, --
Alan Knight [|], Cincom Smalltalk Development
|
Re: Problem with nil superclass in vw7.4.1
|
|
Hi List, Alan, Mark:
I know that this has been reported only a couple of days ago, but is there a fix around? I just found out today that after adding an i.v. to our proxies, all the hierarchy was removed from the PartialHierarchy tab of the RB :( (although still visible in the Package tab). Sending #addToSuper to the class seems to put things back in order, although I don't know if that may have any side effects. Thanks in advance, Andrés Alan Knight escribió: > Hmm, that definitely doesn't seem healthy. Created AR 53828. > > At 06:39 AM 2/6/2008, Mark Plas wrote: >> Hi, >> >> If I define this class in a vanilla 7.4.1 image (with a NIL superclass): >> >> Smalltalk defineClass: #TestRoot >> superclass: nil >> indexedType: #none >> private: false >> instanceVariableNames: '' >> classInstanceVariableNames: '' >> imports: '' >> category: 'OldBrowsers' >> >> and I print the following expression: >> >> Class rootsOfTheWorld >> >> I get: >> >> OrderedCollection (TestRoot Object) >> >> If I then add an instance variable to TestRoot >> >> Smalltalk defineClass: #TestRoot >> superclass: nil >> indexedType: #none >> private: false >> instanceVariableNames: 'test ' >> classInstanceVariableNames: '' >> imports: '' >> category: 'OldBrowsers' >> >> And I print: >> >> Class rootsOfTheWorld >> >> I get: >> >> OrderedCollection (Object) >> >> The class TestRoot is no longer there! Removing the instance variable or adding it again doesn’t help. One of the consequences of this is that finding senders or implementors of methods never looks in the hierarchy of the class TestRoot which can be annoying. The same happens in a vw7.5 image. I don’t know what other problems may come from this but it doesn’t sound healthy. >> >> Is there a fix for this? >> >> Thanks, >> Mark >> > > -- > Alan Knight [|], Cincom Smalltalk Development > [hidden email] > [hidden email] > http://www.cincom.com/smalltalk > |
|
|
Hi Andres,
What I did was to introduce a dummy superclass for my proxy that contains no instance variables. If I need to add instvars I do it on a subclass and then things seemed to work fine. I looked at Lens.LensAbsentee and Protocols.ProtoObject: they also have (by coincidence?) a general superclass without instvars. So I did the same with my class. Not a real fix, but it works good enough for me. Mark -----Original Message----- From: Andres Fortier [mailto:[hidden email]] Sent: zondag 10 februari 2008 23:36 To: [hidden email] Subject: Re: Problem with nil superclass in vw7.4.1 Hi List, Alan, Mark: I know that this has been reported only a couple of days ago, but is there a fix around? I just found out today that after adding an i.v. to our proxies, all the hierarchy was removed from the PartialHierarchy tab of the RB :( (although still visible in the Package tab). Sending #addToSuper to the class seems to put things back in order, although I don't know if that may have any side effects. Thanks in advance, Andrés Alan Knight escribió: > Hmm, that definitely doesn't seem healthy. Created AR 53828. > > At 06:39 AM 2/6/2008, Mark Plas wrote: >> Hi, >> >> If I define this class in a vanilla 7.4.1 image (with a NIL superclass): >> >> Smalltalk defineClass: #TestRoot >> superclass: nil >> indexedType: #none >> private: false >> instanceVariableNames: '' >> classInstanceVariableNames: '' >> imports: '' >> category: 'OldBrowsers' >> >> and I print the following expression: >> >> Class rootsOfTheWorld >> >> I get: >> >> OrderedCollection (TestRoot Object) >> >> If I then add an instance variable to TestRoot >> >> Smalltalk defineClass: #TestRoot >> superclass: nil >> indexedType: #none >> private: false >> instanceVariableNames: 'test ' >> classInstanceVariableNames: '' >> imports: '' >> category: 'OldBrowsers' >> >> And I print: >> >> Class rootsOfTheWorld >> >> I get: >> >> OrderedCollection (Object) >> >> The class TestRoot is no longer there! Removing the instance variable or adding it again doesn't help. One of the consequences of this is that finding senders or implementors of methods never looks in the hierarchy of the class TestRoot which can be annoying. The same happens in a vw7.5 image. I don't know what other problems may come from this but it doesn't sound healthy. >> >> Is there a fix for this? >> >> Thanks, >> Mark >> > > -- > Alan Knight [|], Cincom Smalltalk Development > [hidden email] > [hidden email] > http://www.cincom.com/smalltalk > |
Re: Problem with nil superclass in vw7.4.1
|
|
In reply to this post by Mark Plas
I got bored and this sounded like a fun problem, so I had a bit of a
look this afternoon. It seems that BehaviorBuilderRecord>>#doBecome in the process of swapping the old class with the new class, registers both the old and the new class with their superclasses. BehaviorBuilderRecord>>#cleanup (which is called after #doBecome), then removes the old class from its superclass. This seems reasonable, except that Class>>#addToSuper calls #addToSuper on the metaclass and both the old and the new class have the same metaclass. This means that we try to add the metaclass twice (the second time does nothing because it's already there), then remove it once. One possible fix for this is to change BehaviorBuilderRecord>>#doBecome to not call "self archive addToSuper.", then change BehaviorBuilderRecord>>#cleanup to: cleanup archive := nil Not sure if this is the right way to fix it. The code seems a little over-engineered to me and making the above change weakens the case for #doBecome having that name, but since it's not called from anywhere else in the system. Hope that helps, David |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |