>> Come one andreas
>>
>> 	Image abandoneSources


Ok call it ImageVMSupport this is already better than SystemDictionary 
which is a namespace.

RuntimeImageSupport is much cooler but now people will complain this is 
too long to type.........

>>
>> Does not tell you something?
>
> I'd be looking for a class Image either if I
> * look for graphical objects (which are often referred to as "image")
> * if I would want to know about what Squeak's representation for its 
> .image
> file is (such as in ImageSegment)
> but I'd definitely not look for some class "Image" in the context of
> #abandonSources. Sorry.
>
>> Please tell me that I'm wrong and stupid to lose my time cleaning
>> Squeak and I stop. Seriously. No joke. I have something else that
>> hearing that.
>
> I'm not necessarily saying that. I'm telling you to carefully consider 
> *how*
> you clean up things (and I thought you were asking for opinions about 
> this).
>
> To me it seems particularly important to come up with clear concepts 
> for
> utility methods that we want to move out of places where they currently
> live. These methods are likely to be used from lots of places and 
> moving
> them around "randomly" is good recipe for entirely needless
> incompatibilities.
>
> SystemNavigation is a good example in this regard - a clear concept,
> encapsulating lots of utility methods but clearly scoped. But for those
> utility methods where we don't have a clear concept it might be 
> worthwhile
> to keep them in SystemDictionary for as long as we need to find a good
> concept.
>
> So what I'm rather saying is: Don't force it. If you *do* have a useful
> concept that scales then use it (like SystemNavigation). But don't move
> methods around randomly just because you think they don't belong in one
> place but have no good idea about any other place they might belong to.

I do not why you continue to think that my notion of design is random 
distribution.
I thought you knew me better.

>
> Cheers,
>   - Andreas
>
>
>