>> I agree that SystemNavigation is ugly, but *a lot* of existing code >> depends on it. > > Well if I start forking all the classes that we should fix because there are > used it will be endless. > I was thinking to start also to look at senders and use deprecate. > > do you have a lot of external tools that use it?
Yes, all tools use it: Monticello, Paragraph Editor (new and old), OmniBrowser, eCompletion, Refactoring Engine. Now I removed its use from the BrowserEnvironment in the refactoring engine itself. There are still a couple of references though, where people used the wrong abstraction layer when implementing stuff (platform code instead of the abstraction of the refactoring engine). > So what do you suggest? > Separating BrowserEnvironment and its superclass from RB and starting to > - check its api > - improve it > - migrate caller of systemNavigation -> BrowserEnvironment (rename > browserEnvironment) Yeah, maybe one step would be to split the refactoring engine into smaller and independent packages: AST-Core (that already is separate) Refactoring-Environment (this is currently part of Refactoring-Core, but would work independently) Refactoring-Changes (this is currently part of Refactoring-Core, but would work independently) Refactoring-Refactorings (this is currently part of Refactoring-Core and depends on all of the above) Refactoring-Lint (this is currently part of Refactoring-Core and depends on all of the above) Like this Pharo could integrate Refactoring-Environment and Refactoring-Changes independently. I'll see if I can repackage the refactoring browser a bit, might take a while though because the tests are not that nicely separated. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
