On 11/8/08, Noury Bouraqadi <bouraqadi@ensm-douai.fr> wrote:
Thanks Lukas for the feedback. Now I have some questions:
-For fuctionality 1 : Because of the dependency with the RefactoringBrowser, which obviously shouldn't be in the core image. Does it make sense to have it in an external package ? It's handy to avoid using multiple tools when renaming a Monticello Package and the corresponding class prefixes. But, may be should I reimplement without reusing the RefactoringBrowser ?
Renaming all classes of a package doesn't really make sense without fixing all references automatically. It is certainly a pain to do without the refactoring tools. But, as I said, this functionality is already part of the OB refactoring tools.
-Is fuctionality 2 useful for other people than me ?
It is definitely useful. For the Seaside 2.9 repackaging effort we had to rename sevaral packages manually. A solid tool would be a huge advantage. Cheers, Lukas Fixing the issues
you identified wouldn't be a big challenge.
Noury On 7 nov. 08, at 22:26, Lukas Renggli wrote:
The package MonticelloPackageRenaming-Noury.1 introduces 2 new menu items into the Monticello Browser, by overriding and extending several methods in Monticello. If this code is included with Pharo, it should become part of Monticello itself. There are 4 test cases included.
Below I review the two new functionalities independently:
1. Replace Classes Prefix: This functionality is useful, however the implementation depends on the presence of the Refactoring Browser. Furthermore this functionality is already present in the Refactoring Browser (OB-Regex) in a more generic fashion. Open | Rewrite Class allows one to batch rename, batch copy and batch create a set of classes using regular expressions.
2. Rename Package: This functionality renames class categories and method protocols to match the new package name. The code also takes care of the dependencies and removing traces of the old package in the Monticello Browser. It does not depend on external functionality. There are however 3 major problems with the implementation: (1) Class extensions extinct if they do not match the package names in a case-sensitive way. PackageInfo treats class categories case-sensitive, but protocols are handled case-insensitive. (2) Packages that share the same prefix are wrongly renamed, even if PackageInfo does not consider them to be from the same package (for example Morphic and MorphicExtras). (3) The ancestry of the renamed package is not preserved, what makes merging packages across renaming impossible. Though, I don't know if such a functionality would be possible with Monticello at all?
Given the number of problems I don't suggest to include these extensions for now.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Noury Bouraqadi ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury
European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch