On Sat, Sep 4, 2010 at 1:08 PM, Lukas Renggli
<renggli@gmail.com> 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
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.
If you finally do this Lukas, let me know so that I update ConfigurationOf ...
Lukas