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 ?
My feeling is that the RBengine should be in the system (not core) at
the same time the browsers are in. Because renaming a class
in the refactoring way is just the way to go since 10 years or more.
-Is fuctionality 2 useful for other people than me ? Fixing the
issues you identified wouldn't be a big challenge.
Yes renaming a package would be cool.
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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
