On 11 March 2010 17:12, Marcus Denker <[email protected]> wrote: > > On Mar 11, 2010, at 3:58 PM, Mariano Martinez Peck wrote: > >> >> > What do you think? >> > >> >> allClassesDo: [:class | class organization setDefaultList: #() ] >> >> >> Seems to be more complicated than that. There is a problem with the >> notifications.... >> >> Now, I added to ClassOrganizer the method >> >> putAllSelectorInDefaultCategory >> self elementArray do: [:each | self classify: each under: self class >> default suppressIfDefault: false] >> >> And then I evaluate: >> >> Smalltalk allClassesDo: [:each | each organization >> putAllSelectorInDefaultCategory]. >> Smalltalk allClassesDo: [:each | each organization removeEmptyCategories]. >> Smalltalk garbageCollect. >> >> >> That seems to work. I mean, all method of all classes uses the same >> category. As it is a ByteSymbol, there is only one instance. However, after >> saving the image, is it is bigger than before evaluating that.... >> >> there is of course something I am not understanding. Is there some chapter, >> tutorial or link to read about all the ClassOrganizer stuff ? >> > no... all the ClassOrganizer stuff is so old that it seriously needs to be > replaced... it looks like it comes from a time when the only collection > available was an Array :-) > It's very badly done from today's OO design perspective. Hard to understand, > difficult to use (I can never remember how to get all classes of one > category, for example). > And it's not OO. Categories are not Object, for example. They are just > symbols. Asking for classes of one category gives you names, not classes. > > In addition it's slow. > e.g. we discovered in 3.9 that asking a class for it's category needed to > iterate over the whole array, making it very slow. Than we saw that there was > an unused "category" iVar in Class, which we used to cache the category. MC > suddenly became 2 times faster in loading. >
Marcus, once before, i did examined the ClassOrganizer implementation. Yes, it is slow, complex and using Arrays. But i know why - it was designed for compactness to have a small memory footprint. So, all of good things, like simplicity, good OO etc etc was sacrificed towards having less memory in image. > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
