|Anonymous | Login||01-19-2020 11:29 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0004624||[Squeak] ToDo||minor||always||08-23-06 09:48||10-03-09 19:34|
|Summary||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 = $*].
|Attached Files||ExtCatagoriesForSq7159.text [^] (6,579 bytes) 08-31-08 18:25|
(0012550 - 95 - 95 - 95 - 95 - 95 - 95)
|I have no idea what this report is trying to say. I expect/hope that this is resolved/closable.|
(0012559 - 1669 - 1845 - 1845 - 1845 - 1845 - 1845)
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.
Yours in curiosity and service, --Jerome Peace
|08-23-06 09:48||ducasse||New Issue|
|08-23-06 09:48||ducasse||Status||new => assigned|
|08-23-06 09:48||ducasse||Assigned To||=> KenCausey|
|08-24-06 01:03||KenCausey||Assigned To||KenCausey => MarcusDenker|
|08-24-06 01:03||KenCausey||Category||Any => ToDo|
|08-24-06 01:03||KenCausey||Description Updated|
|08-27-06 16:55||ducasse||version||=> 3.10|
|08-30-08 00:57||Keith_Hodges||Assigned To||MarcusDenker => Keith_Hodges|
|08-30-08 00:58||Keith_Hodges||Note Added: 0012550|
|08-31-08 18:25||wiz||File Added: ExtCatagoriesForSq7159.text|
|08-31-08 18:44||wiz||Note Added: 0012559|
|10-03-09 19:34||Keith_Hodges||Assigned To||Keith_Hodges => andreas|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
52 total queries executed.|
37 unique queries executed.