On Jan 25, 2010, at 09:57 , Mariano Martinez Peck wrote: > On Mon, Jan 25, 2010 at 9:02 AM, Adrian Lienhard <[email protected]> wrote: > >> Hi Stef >> >> We can move the few classes related to image segments into a separate >> package in SqueakSource. The system (ideally) does not depend on them so it >> should not be too hard to package them separately. >> >> > There are several things I would like to say: > > - The ImageSegment code really suc.. and it is very difficult to understand, > maintain and test. It is full of etoys, morphic, project and other stuff. > - There are a lot of methods that do a lot of black magic > - The code is VERY fragile and may be broke any time (if it is not already > broken) > > However, > > - Some people use it > - It is fast
I think image segments is a very nice idea and it works very well if you know how to use them. The core, which is used for basic store/load, is not that complicated. But image segments have been hacked in ugly ways for project persistency. Hence, there is a lot of complexity that is not needed. > If you ask if we should remove it form core, I would say: > > - It won't very VERY easy to completely remove them. There are some places > where ImageSegment are inside the code and won't be easy to remove. Or at > least, leave the code with Smalltalk at: #ImageSegment ifPresent: [blah..] > Look for example, > Behavior >> allInstancesEverywhereDo: > ClassDescription >> updateInstancesFrom: > All those doGently and isInMemory I don't think it is very hard. Methods such as allInstancesEverywhereDo: can be deleted. They implement iterating over object in segments that may be stored on disk. This is too much magic in my eyes. I would only keep the core to do basic segment store/load. > So...remove then would be easy, but put them in a separate package, still > working and without Smalltalk at: ifPresent I think it would be difficult. > > I have already clean, fix and test it as much as possible. I will let them > in Pharo and as Martin said, getting it better when someone has time and is > willing to do it. When I find some time I'll try to continue from your work and extract them into a separate package. > Another problem is that if we remove ImageSegment to an external package, > will be soon outdated and nobody will maintain it. I believe it may be even the other way round. If image segments (or any other package) is external to the image, it is easier to commit changes. Even though image segments have been around for 10 years inside Squeak they have not been maintained, so it can only get better ;) Cheers, Adrian > > Cheers > > Mariano > > > Adrian >> >> On Jan 22, 2010, at 21:35 , Stéphane Ducasse wrote: >> >>> hi guys >>> >>> the more I read about imageSegments the more I would like to remove them >> (or to package them >>> carefully - not sure that this is possible) and may be add a new class >> to >>> just have one simple way of invoking the save (but not swapping back in) >>> >>> I think that mariano diving into them is a great phd exercise but on the >> long run >>> I see it as a brittle mechanism. >>> >>> what do you think? >>> >>> Stef >>> _______________________________________________ >>> 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
