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

Reply via email to