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
