Mantis - Squeak
Viewing Issue Advanced Details
4624 ToDo minor always 08-23-06 09:48 10-03-09 19:34
ducasse  
andreas  
normal  
assigned 3.10  
open  
none    
none  
0004624: lot of class extensions for MC are broken
    | set |
    set := Set new.
    Smalltalk allClasses do: [:each |
            set addAll: each organization categories.].
    ^ set select: [:each | each first = $*].
 ExtCatagoriesForSq7159.text [^] (6,579 bytes) 08-31-08 18:25

Notes
(0012550)
Keith_Hodges   
08-30-08 00:58   
I have no idea what this report is trying to say. I expect/hope that this is resolved/closable.
(0012559)
wiz   
08-31-08 18:44   
Hi Keith,

My guess is that Stef meant the extention catagories in the image no longer strictly correspond to MC saved methods.

I've uploaded a list from squeak 3.10.2 (sq7159) created from Stef's code snippet.

So my take is this is a complaint about the internal packaging of the methods.

The resolution comes with deciding how squeak is organized/stored/maintained. Which you and matthew (packages) and Colin (MC2) are redoing.

IMHO the problem comes from the overloading of the catagories function with the packaging responsabilities. I think many were more comfortable when catagories were an informal organizing of methods. Now that they are formal packaging tools it is a lot more difficult to use them.

o They MUST be kept in sync with the packages when used as extentions.
o If the name is hypenated does it refer to a sepate file or is it part of the the root name.
o If the name is multi-hypenated, the above question applies at each hypen boundry.

If code is extention catagoried does that imply that it is maintained in a package on squeaksource somewhere? Or has it been put into the image with a change set.

Stef's 3.9 insisted on mostly everything being in a mcz package. The 3.10 team I think relaxed this requirement. And 3.10 has been release with "dirty" MC packages. And probably some that are not in packages.

=======

As for the disposition of this report, I agree it is not specific enough to have a clear fix. And I suspect even if it were clear the fix would prove elusive. So resolving the report as cannot/will not fix is probably appropriate.

Hth,
  
Yours in curiosity and service, --Jerome Peace