On 11/8/08, Noury Bouraqadi <[EMAIL PROTECTED]> 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 >> [email protected] >> 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
