Refactoring-Spelling depends on Refactoring-Critics. Refactoring-Tests-Spelling depends on Refactoring-Tests-Critics.
Lukas 2010/9/25 Mariano Martinez Peck <[email protected]>: > > > 2010/9/5 Lukas Renggli <[email protected]> >> >> I've split the refactoring model into various packages as outlined in >> the previous mail. >> >> The dependencies between the tests are slightly problematic, but will >> eventually be fixed as depicted in red in the attached dependency >> graph. It shouldn't matter for loading, so there is no hurry. >> > > Lukas, and what happens with 'Refactoring-Spelling' ?? > > is this still valid? > > package: 'Refactoring-Spelling' with: [ > spec requires: 'Refactoring-Core'. > spec postLoadDoIt: #postLoadRBSpelling ]; > package: 'Refactoring-Tests-Spelling' with: [ spec requires: > 'Refactoring-Spelling'. ]. > > > thanks > > mariano > > >> >> Thank you for updating the configuration Mariano. Note that >> OB-Refactory depends on all the non-test packages. >> >> Lukas >> >> On 4 September 2010 14:01, Stéphane Ducasse <[email protected]> >> wrote: >> > >> > On Sep 4, 2010, at 1:08 PM, Lukas Renggli wrote: >> > >> >>>> 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 >> > >> > yes this would be good so that we can start do the idea with the >> > integration related to systemDictionary been a potential leave of the >> > composition >> > tree we talked last time you visit us. >> > >> >> Refactoring-Core, but would work independently) >> >> Refactoring-Changes (this is currently part of Refactoring-Core, >> >> but would work independently) >> > >> > yes I'm curious to see if/how we could use changes to represent >> > changeset. >> > >> > >> >> 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. >> > >> > I imagine. >> > Now incremental changes is the only way for us :) >> >> >> >> Lukas >> >> >> >> -- >> >> Lukas Renggli >> >> www.lukas-renggli.ch >> >> >> >> _______________________________________________ >> >> 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 >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> 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 > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
