Bug/infelicity in method category fileout

I've been meaning to mention this for about a year.  Probably now is the
worst time to do so, with a new release pending.  Sorry!

I use quite a lot custom VirtualMethodCategories (things like '*-with
undefined sends', '*-never referred to', '*-CU added', etc).  The problem is
that when a method is filed-out, the file-out includes all the categories
the method belongs to, including the dynamically-computed ones.  I think
that's wrong.

Part of the problem is that makes package writing slower than it needs be,
but the main problem is that if/when someone loads any of my code, they end
up with methods in totally irrelevant categories which look dynamic but
aren't.

It's not a major problem (in fact it doesn't really affect *me* at all, just
the people who make use any of my code...), but it'd be nice if you could
fix it.

TIA.

    -- chris

Chris

You wrote in message
news:[hidden email]...
> I've been meaning to mention this for about a year.  Probably now is the
> worst time to do so, with a new release pending.  Sorry!
>
> I use quite a lot custom VirtualMethodCategories (things like '*-with
> undefined sends', '*-never referred to', '*-CU added', etc).  The problem
is
> that when a method is filed-out, the file-out includes all the categories
> the method belongs to, including the dynamically-computed ones.  I think
> that's wrong.

That was actually intentional, the idea being that if one imported the code
into another Smalltalk which doesn't have virtual method categories then
that information could still be retained. However since most St's don't
support multiple method categories, it's a bit pointless, so on the whole I
would agree that the virtual/pseudo categories should not be included in the
fileout, with the exception of public/private. It may be sorted in the next
release if trivial (which I suspect it is).

Regards

Blair