[Pharo-project] Issue 1634: Object allSubInstances slooooow
Pharo image: Pharo | Pharo-core PharoCore1.0rc1 Latest update: #10502 VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Steps to reproduce: 1.[Object allSubInstances size inspect] timeToRun 375479 (6 minutes) with fix [Object allSubInstances size inspect] timeToRun 22335 (22 seconds) Attached treats Object as a special case, and takes advantage of primitive in SystemNavigation>>allObjectsDo: Test also attached (it's slow without the mod) http://code.google.com/p/pharo/issues/detail?id=1634 http://code.google.com/p/pharo/issues/detail?id=1634 http://n2.nabble.com/file/n4189848/BehaviorTest-testAllObjectsPerformance.st BehaviorTest-testAllObjectsPerformance.st http://n2.nabble.com/file/n4189848/Behavior-allSubInstancesDo.st Behavior-allSubInstancesDo.st http://n2.nabble.com/file/n4189848/Behavior-allSubInstancesDo.st Behavior-allSubInstancesDo.st -- View this message in context: http://n2.nabble.com/Issue-1634-Object-allSubInstances-slooooow-tp4189848p41... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Stan Shepherd wrote:
Pharo image: Pharo | Pharo-core PharoCore1.0rc1 Latest update: #10502 VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074]
Steps to reproduce: 1.[Object allSubInstances size inspect] timeToRun 375479 (6 minutes)
with fix [Object allSubInstances size inspect] timeToRun 22335 (22 seconds)
Attached treats Object as a special case, and takes advantage of primitive in SystemNavigation>>allObjectsDo:
It looks like with this change, Object allSubInstances would return instances of classes that do not inherit from Object, for instance objects that inherit from ProtoObject. Perhaps the special case should go on ProtoObject? Or a test could be made of how many subclasses a class has, and if it's over some arbitrary number just iterate through all objects and test each one for isKindOf:? Don't know how fast that would be, maybe it's not faster. But probably slow is preferable to incorrect. If you just want "all objects" and don't care about their class then you can always use SystemNavigation>>allObjectsDo: rather than allSubInstances. Regards, -Martin
On Fri, Dec 18, 2009 at 6:04 PM, Martin McClure <martin@hand2mouse.com>wrote:
Stan Shepherd wrote:
Pharo image: Pharo | Pharo-core PharoCore1.0rc1 Latest update: #10502 VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074]
Steps to reproduce: 1.[Object allSubInstances size inspect] timeToRun 375479 (6 minutes)
with fix [Object allSubInstances size inspect] timeToRun 22335 (22 seconds)
Attached treats Object as a special case, and takes advantage of primitive in SystemNavigation>>allObjectsDo:
It looks like with this change, Object allSubInstances would return instances of classes that do not inherit from Object, for instance objects that inherit from ProtoObject.
Perhaps the special case should go on ProtoObject? Or a test could be made of how many subclasses a class has, and if it's over some arbitrary number just iterate through all objects and test each one for isKindOf:? Don't know how fast that would be, maybe it's not faster. But probably slow is preferable to incorrect. If you just want "all objects" and don't care about their class then you can always use SystemNavigation>>allObjectsDo: rather than allSubInstances.
+1. I don't think there's any justification for this hack. It's possible to have another root to the hierarchy apart from ProtoObject. Further, a bit weak, but allSubInstancesDo: has ordering properties; it will evaluate the block with all instances of a class followed by all instances of another and so on; it will visit all instances of any superclass before it visits any instances of subclasses, and that could be useful. If you want to use allObjectsDo: use it. Of course allSubInstancesDo: is slow; it makes as many scans of the system as there are classes (Metaclass avoids the scan by evaluating with soleInstance). But that's not a justification for special-casing one use of it to a freely accessible but different alternative.
Regards,
-Martin
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Eliot Miranda-2 wrote:
On Fri, Dec 18, 2009 at 6:04 PM, Martin McClure <martin@hand2mouse.com>wrote:
Stan Shepherd wrote:
Pharo image: Pharo | Pharo-core PharoCore1.0rc1 Latest update: #10502 VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074]
Steps to reproduce: 1.[Object allSubInstances size inspect] timeToRun 375479 (6 minutes)
with fix [Object allSubInstances size inspect] timeToRun 22335 (22 seconds)
Attached treats Object as a special case, and takes advantage of primitive in SystemNavigation>>allObjectsDo:
It looks like with this change, Object allSubInstances would return instances of classes that do not inherit from Object, for instance objects that inherit from ProtoObject.
Perhaps the special case should go on ProtoObject? Or a test could be made of how many subclasses a class has, and if it's over some arbitrary number just iterate through all objects and test each one for isKindOf:? Don't know how fast that would be, maybe it's not faster. But probably slow is preferable to incorrect. If you just want "all objects" and don't care about their class then you can always use SystemNavigation>>allObjectsDo: rather than allSubInstances.
+1.
I don't think there's any justification for this hack. It's possible to have another root to the hierarchy apart from ProtoObject. Further, a bit weak, but allSubInstancesDo: has ordering properties; it will evaluate the block with all instances of a class followed by all instances of another and so on; it will visit all instances of any superclass before it visits any instances of subclasses, and that could be useful. If you want to use allObjectsDo: use it. Of course allSubInstancesDo: is slow; it makes as many scans of the system as there are classes (Metaclass avoids the scan by evaluating with soleInstance). But that's not a justification for special-casing one use of it to a freely accessible but different alternative.
Regards,
-Martin
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Eliot Miranda-2 wrote:
I don't think there's any justification for this hack.
Quite so. It was late, and I'd thought better of it by morning. However, don't feel you need to spare my feelings ;) Taking a step back, Object allSubinstances size seems to be a common proxy measure for the size/bloat/complexity of an image. (E.g. http://www.object-arts.com/docs/index.html?how_many_objects.htm ). Running it on a large production system would potentially be very slow. It could also be something a current Smalltaker would run to check out Pharo, in which case a coffee break would be warranted. So from a marketing of Pharo perspective, 6 minutes seems too long to me. Yes, an experienced user will avoid it. I have no proposal as to how to catch that case while avoiding a hack. Adding a specific allSubinstances to Object class would break inheritance chain to Behavior. In the meantime, perhaps there should be an alternative simple measure available: SystemNavigation>>allObjects "A fast way to list all current objects in the image. n.b. this will include the classes ImageSegmentRootStub MessageCatcher TestCoverage DynamicBindingsInfo, and possibly others, that do not inherit from Object. These classes probably have no instances, but it is not safe to assume this" | aCollection | aCollection := OrderedCollection new. self allObjectsDo: [:x | x == aCollection ifFalse: [aCollection add: x]]. ^ aCollection with a comment in allSubInstances "for Prototype>>allSubInstances, Object>>allSubInstances,consider using SystemNavigation>>allObjects. This is much faster. see comment there" Martin McClure wrote:
It looks like with this change, Object allSubInstances would return instances of classes that do not inherit from Object, for instance objects that inherit from ProtoObject.
Yes. It doesn't currently, but it could. See comment above. Martin McClure wrote:
Or a test could be made of how many subclasses a class has, and if it's over some arbitrarynumber just iterate through all objects and test each one for isKindOf:? Don't know how fast that would be, maybe it's not faster.
Yes, I looked at that: multi single pass pass Collection 18650 29448 82 subclasses, multipass 50% faster BorderedMorph 26301 7464 206 subclasses, singlepass 3x faster GRObject 113717 6969 742 subclasses, singlepass 14x faster. Breakeven point is around 100 subclasses. Mostly allSubInstances is used in housekeeping tasks, so it's not a big issue. As it's mostly used in housekeeping, a lot of the applications would probably be fine with the unordered, one pass version. I'll do a bit of digging into whether there are any meaningful performance implications. ...Stan Behavior>>allSubInstancesDoInOnePass: attached if anyone wants to benchmark http://n2.nabble.com/file/n4192013/Behavior-allSubInstancesDoInOnePass.st Behavior-allSubInstancesDoInOnePass.st -- View this message in context: http://n2.nabble.com/Issue-1634-Object-allSubInstances-slooooow-tp4189848p41... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Stan did you compare/have a look at spaceTally because it is also reporting memory consumption and may be we could make everything better. (I just read my mails between two houses fixes). I will take more time this evening if I can. Anyway thanks. I like these kinds of discussions. Because I learn stuff or they make me think and rethink what I think I know Stef On Dec 19, 2009, at 6:11 PM, Stan Shepherd wrote:
Eliot Miranda-2 wrote:
On Fri, Dec 18, 2009 at 6:04 PM, Martin McClure <martin@hand2mouse.com>wrote:
Stan Shepherd wrote:
Pharo image: Pharo | Pharo-core PharoCore1.0rc1 Latest update: #10502 VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074]
Steps to reproduce: 1.[Object allSubInstances size inspect] timeToRun 375479 (6 minutes)
with fix [Object allSubInstances size inspect] timeToRun 22335 (22 seconds)
Attached treats Object as a special case, and takes advantage of primitive in SystemNavigation>>allObjectsDo:
It looks like with this change, Object allSubInstances would return instances of classes that do not inherit from Object, for instance objects that inherit from ProtoObject.
Perhaps the special case should go on ProtoObject? Or a test could be made of how many subclasses a class has, and if it's over some arbitrary number just iterate through all objects and test each one for isKindOf:? Don't know how fast that would be, maybe it's not faster. But probably slow is preferable to incorrect. If you just want "all objects" and don't care about their class then you can always use SystemNavigation>>allObjectsDo: rather than allSubInstances.
+1.
I don't think there's any justification for this hack. It's possible to have another root to the hierarchy apart from ProtoObject. Further, a bit weak, but allSubInstancesDo: has ordering properties; it will evaluate the block with all instances of a class followed by all instances of another and so on; it will visit all instances of any superclass before it visits any instances of subclasses, and that could be useful. If you want to use allObjectsDo: use it. Of course allSubInstancesDo: is slow; it makes as many scans of the system as there are classes (Metaclass avoids the scan by evaluating with soleInstance). But that's not a justification for special-casing one use of it to a freely accessible but different alternative.
Regards,
-Martin
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Eliot Miranda-2 wrote:
I don't think there's any justification for this hack.
Quite so. It was late, and I'd thought better of it by morning. However, don't feel you need to spare my feelings ;)
Taking a step back, Object allSubinstances size seems to be a common proxy measure for the size/bloat/complexity of an image. (E.g. http://www.object-arts.com/docs/index.html?how_many_objects.htm ). Running it on a large production system would potentially be very slow. It could also be something a current Smalltaker would run to check out Pharo, in which case a coffee break would be warranted. So from a marketing of Pharo perspective, 6 minutes seems too long to me. Yes, an experienced user will avoid it. I have no proposal as to how to catch that case while avoiding a hack. Adding a specific allSubinstances to Object class would break inheritance chain to Behavior.
In the meantime, perhaps there should be an alternative simple measure available:
SystemNavigation>>allObjects "A fast way to list all current objects in the image. n.b. this will include the classes ImageSegmentRootStub MessageCatcher TestCoverage DynamicBindingsInfo, and possibly others, that do not inherit from Object. These classes probably have no instances, but it is not safe to assume this" | aCollection | aCollection := OrderedCollection new. self allObjectsDo: [:x | x == aCollection ifFalse: [aCollection add: x]]. ^ aCollection
with a comment in allSubInstances "for Prototype>>allSubInstances, Object>>allSubInstances,consider using SystemNavigation>>allObjects. This is much faster. see comment there"
Martin McClure wrote:
It looks like with this change, Object allSubInstances would return instances of classes that do not inherit from Object, for instance objects that inherit from ProtoObject.
Yes. It doesn't currently, but it could. See comment above.
Martin McClure wrote:
Or a test could be made of how many subclasses a class has, and if it's over some arbitrarynumber just iterate through all objects and test each one for isKindOf:? Don't know how fast that would be, maybe it's not faster.
Yes, I looked at that: multi single pass pass Collection 18650 29448 82 subclasses, multipass 50% faster
BorderedMorph 26301 7464 206 subclasses, singlepass 3x faster
GRObject 113717 6969 742 subclasses, singlepass 14x faster.
Breakeven point is around 100 subclasses.
Mostly allSubInstances is used in housekeeping tasks, so it's not a big issue. As it's mostly used in housekeeping, a lot of the applications would probably be fine with the unordered, one pass version.
I'll do a bit of digging into whether there are any meaningful performance implications.
...Stan
Behavior>>allSubInstancesDoInOnePass: attached if anyone wants to benchmark http://n2.nabble.com/file/n4192013/Behavior-allSubInstancesDoInOnePass.st Behavior-allSubInstancesDoInOnePass.st -- View this message in context: http://n2.nabble.com/Issue-1634-Object-allSubInstances-slooooow-tp4189848p41... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
Stan did you compare/have a look at spaceTally because it is also reporting memory consumption and may be we could make everything better. (I just read my mails between two houses fixes). I will take more time this evening if I can. Anyway thanks. I like these kinds of discussions. Because I learn stuff or they make me think and rethink what I think I know
Stef
SpaceTally uses allInstances for each class. [(SpaceTally new systemWideSpaceTally asSortedCollection: [:a :b | a spaceForInstances > b spaceForInstances]) asArray inspect] timeToRun 363332 on a slow machine. Could probably be made somewhat faster by keeping a count of all classes' instances during one pass. Senders of allSubInstances with their number of subclasses ---------------------------------------------------------- a MethodReference Behavior >> #inspectSubInstances->3396 a MethodReference Morph class >> #morphsUnknownToTheirOwners->221 a MethodReference Morph >> #morphsUnknownToTheirOwners->221 a MethodReference Set class >> #rehashAllSets->21 a MethodReference Set >> #rehashAllSets->21 a MethodReference UITheme class >> #closeExampleDialogs->6 a MethodReference UITheme >> #closeExampleDialogs->6 a MethodReference FT2Handle class >> #shutDown:->5 a MethodReference FT2Handle >> #shutDown:->5 a MethodReference Categorizer class >> #sortAllCategories->4 a MethodReference Categorizer >> #sortAllCategories->4 a MethodReference TTCFont class >> #recreateCache->2 a MethodReference TTCFont >> #recreateCache->2 a MethodReference Symbol class >> #rehash->2 a MethodReference Symbol >> #rehash->2 a MethodReference StrikeFont class >> #setupDefaultFallbackFont->2 a MethodReference StrikeFont >> #setupDefaultFallbackFont->2 a MethodReference WAProcessStatus >> #processes->0 a MethodReference Utilities class >> #closeAllDebuggers->0 a MethodReference Utilities >> #closeAllDebuggers->0 ...etc Morph morphsUnKnownToTheirOwners timeToRun is 10s; could be faster, but has no senders. Senders of allSubInstancesDo: with their number of subclasses ---------------------------------------------------------- a MethodReference Behavior >> #allSubInstances->3396 a MethodReference Behavior >> #allInstancesEverywhereDo:->3396 a MethodReference ClassDescription >> #updateInstancesFrom:->3395 a MethodReference WASqueakStatusItem >> #numberOfSessions->8 a MethodReference MCFileBasedRepository class >> #flushAllCaches->5 a MethodReference MCFileBasedRepository >> #flushAllCaches->5 a MethodReference PopUpMenu class >> #setMenuFontTo:->3 a MethodReference PopUpMenu class >> #initialize->3 a MethodReference PopUpMenu >> #setMenuFontTo:->3 a MethodReference PopUpMenu >> #initialize->3 a MethodReference ChangeList >> #selectConflictsWith->3 a MethodReference TTCFont class >> #initialize->2 a MethodReference TTCFont >> #initialize->2 a MethodReference StrikeFont class >> #shutDown->2 a MethodReference StrikeFont >> #shutDown->2 a MethodReference WARegistry class >> #clearAll->1 a MethodReference WARegistry >> #clearAll->1 a MethodReference ShortIntegerArray class >> #swapShortObjects->1 a MethodReference ShortIntegerArray >> #swapShortObjects->1 a MethodReference Preferences class >> #smartUpdatingChanged->1 a MethodReference Preferences class >> #setFlapsFontTo:->1 ...etc Metaclass is the sole sender of allInstancesEverywhereDo: Conclusion- there are no cases which clearly need attention, with the possible exception of Object>>allSubInstances It might be worth catching calls to #allSubInstances, #allSubInstancesDo: where subclasses size > say 100, as Martin mentioned. -- View this message in context: http://n2.nabble.com/Issue-1634-Object-allSubInstances-slooooow-tp4189848p41... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Sat, Dec 19, 2009 at 9:11 AM, Stan Shepherd <stan.shepherd414@gmail.com>wrote:
Eliot Miranda-2 wrote:
On Fri, Dec 18, 2009 at 6:04 PM, Martin McClure <martin@hand2mouse.com>wrote:
Stan Shepherd wrote:
Pharo image: Pharo | Pharo-core PharoCore1.0rc1 Latest update: #10502 VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074]
Steps to reproduce: 1.[Object allSubInstances size inspect] timeToRun 375479 (6 minutes)
with fix [Object allSubInstances size inspect] timeToRun 22335 (22 seconds)
Attached treats Object as a special case, and takes advantage of primitive in SystemNavigation>>allObjectsDo:
It looks like with this change, Object allSubInstances would return instances of classes that do not inherit from Object, for instance objects that inherit from ProtoObject.
Perhaps the special case should go on ProtoObject? Or a test could be made of how many subclasses a class has, and if it's over some arbitrary number just iterate through all objects and test each one for isKindOf:? Don't know how fast that would be, maybe it's not faster. But probably slow is preferable to incorrect. If you just want "all objects" and don't care about their class then you can always use SystemNavigation>>allObjectsDo: rather than allSubInstances.
+1.
I don't think there's any justification for this hack. It's possible to have another root to the hierarchy apart from ProtoObject. Further, a
bit
weak, but allSubInstancesDo: has ordering properties; it will evaluate the block with all instances of a class followed by all instances of another and so on; it will visit all instances of any superclass before it visits any instances of subclasses, and that could be useful. If you want to use allObjectsDo: use it. Of course allSubInstancesDo: is slow; it makes as many scans of the system as there are classes (Metaclass avoids the scan by evaluating with soleInstance). But that's not a justification for special-casing one use of it to a freely accessible but different alternative.
Regards,
-Martin
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Eliot Miranda-2 wrote:
I don't think there's any justification for this hack.
Quite so. It was late, and I'd thought better of it by morning. However, don't feel you need to spare my feelings ;)
Sorry Sam :) I had to be blunt. I knew you'd understand :) Forgive me.
Taking a step back, Object allSubinstances size seems to be a common proxy measure for the size/bloat/complexity of an image. (E.g. http://www.object-arts.com/docs/index.html?how_many_objects.htm ). Running it on a large production system would potentially be very slow. It could also be something a current Smalltaker would run to check out Pharo, in which case a coffee break would be warranted. So from a marketing of Pharo perspective, 6 minutes seems too long to me. Yes, an experienced user will avoid it. I have no proposal as to how to catch that case while avoiding a hack. Adding a specific allSubinstances to Object class would break inheritance chain to Behavior.
In the meantime, perhaps there should be an alternative simple measure available:
SystemNavigation>>allObjects "A fast way to list all current objects in the image. n.b. this will include the classes ImageSegmentRootStub MessageCatcher TestCoverage DynamicBindingsInfo, and possibly others, that do not inherit from Object. These classes probably have no instances, but it is not safe to assume this" | aCollection | aCollection := OrderedCollection new. self allObjectsDo: [:x | x == aCollection ifFalse: [aCollection add: x]]. ^ aCollection
with a comment in allSubInstances "for Prototype>>allSubInstances, Object>>allSubInstances,consider using SystemNavigation>>allObjects. This is much faster. see comment there"
Martin McClure wrote:
It looks like with this change, Object allSubInstances would return instances of classes that do not inherit from Object, for instance objects that inherit from ProtoObject.
Yes. It doesn't currently, but it could. See comment above.
Martin McClure wrote:
Or a test could be made of how many subclasses a class has, and if it's over some arbitrarynumber just iterate through all objects and test each one for isKindOf:? Don't know how fast that would be, maybe it's not faster.
Yes, I looked at that: multi single pass pass Collection 18650 29448 82 subclasses, multipass 50% faster
BorderedMorph 26301 7464 206 subclasses, singlepass 3x faster
GRObject 113717 6969 742 subclasses, singlepass 14x faster.
Breakeven point is around 100 subclasses.
Mostly allSubInstances is used in housekeeping tasks, so it's not a big issue. As it's mostly used in housekeeping, a lot of the applications would probably be fine with the unordered, one pass version.
I'll do a bit of digging into whether there are any meaningful performance implications.
...Stan
Behavior>>allSubInstancesDoInOnePass: attached if anyone wants to benchmark http://n2.nabble.com/file/n4192013/Behavior-allSubInstancesDoInOnePass.st Behavior-allSubInstancesDoInOnePass.st -- View this message in context: http://n2.nabble.com/Issue-1634-Object-allSubInstances-slooooow-tp4189848p41... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Eliot Miranda-2 wrote:
Sorry Sam :) I had to be blunt. I knew you'd understand :)
No worries, it made me laugh. I do have a question out of it though. Is there a conceivable situation where you would want Object class to have specific behaviour? If so, as Object class carries the role of backstop case where other classes don't define a method, is there any acceptable way to treat Object class differently? ...Stan -- View this message in context: http://n2.nabble.com/Issue-1634-Object-allSubInstances-slooooow-tp4189848p41... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
"Stan" == Stan Shepherd <stan.shepherd414@gmail.com> writes:
Stan> Eliot Miranda-2 wrote:
Sorry Sam :) I had to be blunt. I knew you'd understand :)
Stan> No worries, it made me laugh. Stan> I do have a question out of it though. Is there a conceivable situation Stan> where you would want Object class to have specific behaviour? If so, as Stan> Object class carries the role of backstop case where other classes don't Stan> define a method, is there any acceptable way to treat Object class Stan> differently? allSubinstances self == Object ifTrue: [^self allSubinstancesSpecialCasedForObject]. ^super allSubinstances -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <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
On Mon, Dec 21, 2009 at 7:18 AM, Stan Shepherd <stan.shepherd414@gmail.com>wrote:
Eliot Miranda-2 wrote:
Sorry Sam :) I had to be blunt. I knew you'd understand :)
No worries, it made me laugh.
I do have a question out of it though. Is there a conceivable situation where you would want Object class to have specific behaviour? If so, as Object class carries the role of backstop case where other classes don't define a method, is there any acceptable way to treat Object class differently?
In general I don't think so. I think it is wrong to assume Object is the root. Squeak currently assumes ProtoObject is the root. In VisualWorks there is a special method rootsOfTheWorld which answers the roots. Smalltalk allows one to create classes that don't inherit form anything else and that is very useful for creating encapsulators. Special casing Object or ProtoObject will break these uses. However, if you were to package up some application in which you knew there would never exist subclasses other than Object, and the performance of allSubInstances was important you would go right ahead and apply that patch. So not in the base, but in a specific app, sure. best Eliot
...Stan -- View this message in context: http://n2.nabble.com/Issue-1634-Object-allSubInstances-slooooow-tp4189848p41... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Eliot Miranda -
Martin McClure -
merlyn＠stonehenge.com -
Stan Shepherd -
Stéphane Ducasse