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 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 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. Another problem is that if we remove ImageSegment to an external package, will be soon outdated and nobody will maintain it. 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
