|Anonymous | Login||02-25-2021 06:03 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|
|0003074||[Squeak] Tools||major||sometimes||02-23-06 23:15||02-23-06 23:15|
|Summary||0003074: Filing out a change set will reorganize class catagories causing MC confusion and woes.|
This issue needs a seed to collect solutions. So I've put it on mantis.
I use the dual change sorter to assemble all the parts of a bug fix.
One pattern in fixing things it that the Object class is used as a backstop for an identity boolean e.g. isFooBar which in general (and therefore in Object) is defined as false and then in the relevant subclass defined true.
Guessing a suitable catagory name usually means inventing a new catagory e.g. ' *MyFooBarPackage-testing ' When the change sorter files out this method it also files out a 'reorganize:' doit for class object which captures this catagory change but also captures the state of all the other catagoies in object at the time of this change. It does this generally behing the coders back and newbie coders who have not run into this problem before are not even aware it is happening.
Later it is published into the image. The catagories for Object have changed in the mean time. The doit causes a reversion/confusion of catagories and messes are created.
That is the essence of the bug.
I've used Object as a example because its a case that frequently comes up. Obviously this applies to any other class touched even slightly as enhancements are produced.
MC and Change sets fileouts have to come to an agreement that creates a win for both.
Thats going to have to take some thinking at the design level.
MC as the newcomer bears the greater load of the responcibility.
At least ethically.
Change sets facilitate creating code that works. It does this by being light and flexible. MC facilitates stability and some history tracking for well defined packages of code.
3.9 is trying to fit everything into MC packages.
Here are some question my curiosity thinks are important:
If the reorganize doit is ignored what catagory will the new method (e.g. isFooBar) be put under on file in?
If I add a method to an already existing catagory does the file out still generate a 'reorganize:' doit?
Is there a way to merge intelligently the existing organization with the reorganizing version?
If I fileout just one method do I get the full class reorganize doit or something else? Does this depend on whether I have put this method in a new catagory or an old one?
Is the asYetUnclassified catagory handled specially in regards to this?
If I define an new method in this catagory do we get a reorgainize doit or not?
The difficulty has come because catagories which were an optional convience for organizing thinking about a code have now become part of a url like path for difining where in the packaging system the code method will be found.
Naming is a multipass process. As more objects get created names change and which object owns which name changes. Ditto catagories.
MC gets in the way of this natural process by prematurely pinning names and catagories to methods and insisting they be semi-permanent.
I look forward to your thoughts and solutions to these matters.
Yours in service, -- Jerome Peace.
|There are no notes attached to this issue.|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
27 total queries executed.|
24 unique queries executed.