Hi, A while ago (2-3 years) I submitted the a change to MC and MC Browser to support package renaming and also changing the initials of all classes in the package. It was rejected because it is possible to have a cleaner alternative implementation that makes use of RB. Unfortunately, I didn't manage to do the change.
Attached my code. A right click on a package name is supposed to Note however that I didn't test it with recent Pharo images. Noury
MonticelloRename-Noury Bouraqadi.1.mcz
Description: Binary data
On 7 déc. 2010, at 00:05, Sven Van Caekenberghe wrote: > Hendrik, > > Thanks for all the help. > > It seems that changing the category programmatically like this works: > > ((SystemOrganization listAtCategoryNamed: 'Zinc-HTTP-New-Client-Server') > collect: [ :className | Smalltalk globals at: className ]) > do: [ :each | each category: 'Zinc-HTTP-Client-Server' ] > > Now MC did pick up the changes. > > Sven > > On 06 Dec 2010, at 16:07, Henrik Johansen wrote: > >> >> On Dec 6, 2010, at 3:52 08PM, Sven Van Caekenberghe wrote: >> >>> >>> On 06 Dec 2010, at 15:42, Henrik Johansen wrote: >>> >>>> If you create a new package with the proper name in the monticello browser >>>> (+Package) though, the recategorized class definitions should end up in >>>> the correct place. >>> >>> OK, Hendrik, +Package might indeed add them to a new Package, and yes one >>> has to do that manually (no problem there), but are they then removed from >>> their original Package ? >>> >>> And what about just renaming a category, these changes do not seem to be >>> picked up. Is there a way to force this ? >>> >>> Or do I have to do a fileout and manually delete each class, even edit the >>> fileout's source code ? >>> >>> Anyway, thanks for the reply. >>> >>> Sven >> >> IIRC, (big if), the package corresponding to the category that was renamed >> will not contain any code if you browse it, but neither is it marked as >> dirty. >> So by default, you probably wouldn't publish the new, empty version of the >> package unless you looked for it specifically. >> New packages created before or after renaming an existing category will not >> be marked dirty as a consequence of the category rename either. >> >> If you change the category of a single class however, both old and new >> package will be marked dirty. (Except if you create the new package after >> performing the rename) >> >> TLDR; >> The packages will contain the correct code, if you publish them. >> Marking packages as dirty does not work for category renames, but do work >> for single class renaming done by recompiling class definition. >> >> Cheers, >> Henry > >
