I recently came across a piece of behaviour which is (sort of) understandable, but I wonder if it is how it is supposed to happen or not. I was running through the potsdam seaside tutorial, and I change the superclass of one of the objects from Object to WAComponent, and accepted the change. All the browser tools treated the class as if its protocol included the messages of WAComponent, but running code that sent WAComponent messages signaled MessageNotUnderstood.
I fixed the problem by running Compiler recompileAllFrom: 'StMenuComponent'.I cannot reproduce the behaviour in a workspace with subclasses of Object/String.
Any ideas on why this happened, but is not reproduceable in the workspace, and is it supposed to work like that?
"Marcin" == Marcin Tustin mm3@zepler.net writes:
Marcin> I recently came across a piece of behaviour which is (sort of) Marcin> understandable, but I wonder if it is how it is supposed to happen or Marcin> not. I was running through the potsdam seaside tutorial, and I change Marcin> the superclass of one of the objects from Object to WAComponent, and Marcin> accepted the change. All the browser tools treated the class as if its Marcin> protocol included the messages of WAComponent, but running code that Marcin> sent WAComponent messages signaled MessageNotUnderstood.
Are you sure you weren't dealing with a previous instance of your old class? I think this kind of a change forks the class def so that new instances have the new superclass, but old instances still have the old class and old superclass (anObsoleteYourClassnameHere).
I could be wrong, but tI think that's how it works.
Am 03.07.2008 um 05:27 schrieb Randal L. Schwartz:
"Marcin" == Marcin Tustin mm3@zepler.net writes:
Marcin> I recently came across a piece of behaviour which is (sort of) Marcin> understandable, but I wonder if it is how it is supposed to happen or Marcin> not. I was running through the potsdam seaside tutorial, and I change Marcin> the superclass of one of the objects from Object to WAComponent, and Marcin> accepted the change. All the browser tools treated the class as if its Marcin> protocol included the messages of WAComponent, but running code that Marcin> sent WAComponent messages signaled MessageNotUnderstood.
Are you sure you weren't dealing with a previous instance of your old class? I think this kind of a change forks the class def so that new instances have the new superclass, but old instances still have the old class and old superclass (anObsoleteYourClassnameHere).
I could be wrong, but tI think that's how it works.
Smalltalk does not work that way. If the class format changed, all existing instance are bulk-migrated to the new class (by creating new instances and doing a forward-become on all of them).
- Bert -
"Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> Smalltalk does not work that way. If the class format changed, all Bert> existing instance are bulk-migrated to the new class (by creating new Bert> instances and doing a forward-become on all of them).
Well, so this *is* the newbies list... I can *ask*... :)
When does "anObsoleteFooClass" show up then? I know there are checks for it, and I think I made one once. When does that happen? I could probably investigate it myself, but maybe someone can answer this and save me a half hour of poking around.
Am 03.07.2008 um 17:40 schrieb Randal L. Schwartz:
"Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> Smalltalk does not work that way. If the class format changed, all Bert> existing instance are bulk-migrated to the new class (by creating new Bert> instances and doing a forward-become on all of them).
Well, so this *is* the newbies list... I can *ask*... :)
When does "anObsoleteFooClass" show up then? I know there are checks for it, and I think I made one once. When does that happen? I could probably investigate it myself, but maybe someone can answer this and save me a half hour of poking around.
When the class is deleted but there are still instances of it.
- Bert -
On Thu, Jul 03, 2008 at 05:44:15PM +0200, Bert Freudenberg wrote:
Am 03.07.2008 um 17:40 schrieb Randal L. Schwartz:
> "Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> Smalltalk does not work that way. If the class format changed, all Bert> existing instance are bulk-migrated to the new class (by creating new Bert> instances and doing a forward-become on all of them).
Well, so this *is* the newbies list... I can *ask*... :)
When does "anObsoleteFooClass" show up then? I know there are checks for it, and I think I made one once. When does that happen? I could probably investigate it myself, but maybe someone can answer this and save me a half hour of poking around.
When the new class is made, the old class is made obsolete. Pointers to the old class coming from Smalltalk, the superclass, and the subclasses are updated. Instances are migrated. After that, the obsolete class will be garbage collected, unless there are pointers to it from other places. These "other places" the class is held can vary wildly:
- Literal references from methods (when the class referenced directly as a global). "SmalltalkImage current fixObsoleteReferences" fixes these. - Various registration services, including, but not limited to: - TheWorldMenu - Flaps - FileList - SystemChangeNotifier - Random caches that are not careful enough. I fixed 3 or 4 cache bugs in Monticello that caused obsolete classes to stick around unnecessarily
beginners@lists.squeakfoundation.org
-
Bert Freudenberg -
Marcin Tustin -
Matthew Fulmer -
merlyn＠stonehenge.com