I'll do it.  Give me a half-hour or so.

Cheers,
Anthony

Scott Wallace <scott.wallace at squeakland.org> wrote:
> No one replied to this, and the work referred to still needs to be 
> done, so I'm sending the request around again.
> 
> Anyone?
> 
> TIA,
> 
>    -- Scott
> 
> At 1:14 PM -0800 11/15/02, Scott Wallace wrote:
> >One of the little loose ends not yet dealt with in 3.4a is 
> >reassigning a few classes to their proper system categories.  If you 
> >look near the bottom of the list of system categories in a browser, 
> >you'll see the categories containing the mis-filed classes; the 
> >errant category names all start with string "Squeak-" or 
> >"Development-", I think.
> >
> >This phenomenon arose from classes that were defined in 3.3a with 
> >the modular organization regime in place.
> >
> >A nice service would be for someone to provide an expression that we 
> >could evaluate in the postscript of an update which would reassign 
> >those classes to proper categories.
> >
> >Here's an example:
> >
> >Notice that in the spurious category "Squeak-Media-Graphics-Files" 
> >we have one class, BMPReadWriter, that needs relocating.
> >
> >We look at its superclass, ImageReadWriter, and we see that it is in 
> >a system category called "Graphics-Files" and that all the JPEG 
> >handling and PNG handling classes are all there as well.  So 
> >obviously this is where BMPReadWriter needs to go.
> >
> >Any volunteers?  I think only around a dozen classes need to be dealt with.
> >
> >Cheers,
> >
> >  -- Scott
> >
> >
> >PS:  One way to formulate the reassignment of a class to a different 
> >category is be to issue the class definition afresh, but with the 
> >desired category.  In practice, that's often what we all do.  This 
> >does trigger an unnecessary recompilation of the entire class, 
> >however.  Is there a lighter weight way, I wonder?  Or, if not, 
> >should there be?