Changing superclass doesn't "work automatically"
Locked
Changing superclass doesn't "work automatically"
 
|
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? _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Changing superclass doesn't "work automatically"
|
|
>>>>> "Marcin" == Marcin Tustin <[hidden email]> 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. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Changing superclass doesn't "work automatically"
|
|
Am 03.07.2008 um 05:27 schrieb Randal L. Schwartz:
>>>>>> "Marcin" == Marcin Tustin <[hidden email]> 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 - _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Changing superclass doesn't "work automatically"
|
|
>>>>> "Bert" == Bert Freudenberg <[hidden email]> 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. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Changing superclass doesn't "work automatically"
|
|
Am 03.07.2008 um 17:40 schrieb Randal L. Schwartz: >>>>>> "Bert" == Bert Freudenberg <[hidden email]> 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 - _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Changing superclass doesn't "work automatically"
|
|
In reply to this post by Randal L. Schwartz
So, this was unexpected behaviour? Certainly the way that Bert describes appears to be what happened in my workspace-based tests.
On 7/3/08, Bert Freudenberg <[hidden email]> wrote: Am 03.07.2008 um 05:27 schrieb Randal L. Schwartz: _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Changing superclass doesn't "work automatically"
|
|
It seems to me anObslote.. class appears when you delete a class, and it is still registered somewhere, still has an instance.
You have a root component called WAComponent, and it is registered with seaside as an application. You delete the class, but not the application, the application will no longer have WAComponent as its root component, but it will be anObsoleteWAComponent.
Is that correct?
On Thu, Jul 3, 2008 at 11:45 AM, Marcin Tustin <[hidden email]> wrote: So, this was unexpected behaviour? Certainly the way that Bert describes appears to be what happened in my workspace-based tests. -- David Zmick /dz0004455\ http://dz0004455.googlepages.com http://dz0004455.blogspot.com _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Changing superclass doesn't "work automatically"
|
|
yes, i think its right :)
On Thu, Jul 3, 2008 at 1:13 PM, David Zmick <[hidden email]> wrote:
-- David Zmick /dz0004455\ http://dz0004455.googlepages.com http://dz0004455.blogspot.com _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Why do obsolete classes stick around?
|
|
In reply to this post by Bert Freudenberg
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 <[hidden email]> 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 -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
«
Return to Squeak - Beginners
|
1 view|%1 views
| Free forum by Nabble | Edit this page |