>>> Well... it is needed for the swapping out of classes. If we remove >>> #isInMemory, we should also remove the whole image segment stub mechanism >>> because it becomes useless without the isInMemory protection.
what I was thinking to remove is the use of isInMemory from SystemDictionary>>allClasses and friends. Now I do not get 100% what you are saying. Do you say that all the queries should be protected against bringing back classes on disc? Stef >>> >> >> >> But was this ever working? Was this ever *used* the last 10 years? Are >> actually all cases covered? So are there enough #isInmemory checks to not >> end up with loading >> everything anyways? >> >> We already removed the *gently variants for iterating over subclasses, for >> example. or the "ifPresentAndInMemory" things.... > > Yes, I did some experiments with it lately and managed to create 4MB images. > Cases which are not protected are indeed a problem. > >>> I would like to keep that working and extract it with the image segments >>> code into an external package. How to do this cleanly is an interesting >>> question, though... >>> >> >> I think we should ask the question: Do we intent to *use* this mechanism *at >> all* the next 5 years? > > Probably not. Nevertheless, I think its a nice idea but if it is not properly > working the chances are small anybody will use. > > In any case, the question of how this *could* be factored out in a clean way > is interesting if we want to further strip and modularize the image. It seems > we are missing appropriate abstractions to modify from external packages > behavior like the #isInMemory sends. Overrides are an unsatisfactory > solution. So there is a limitation to the kind of code can be made external > packages. > > > >> >> -- >> 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 > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
