So the plan would be
- try to group as much as possible imageSegment related code in a
package (without unloading it for now)
- may be offer a simple ImageSlice (going in the direction of what
nestyle did)
- get ready to throw them away.
Stef
On Jan 25, 2010, at 9:57 AM, 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
>
> 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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
