On 11 March 2010 17:12, Marcus Denker <marcus.denker@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.