why RefactoringEnvironment requires AST-Core

Hi lukas

we would like to reuse the BrowserEnvironment for an experiment and I saw


                package: 'Refactoring-Environment' with: [ spec requires: 'AST-Core' ];
                package: 'Refactoring-Tests-Environment' with: [ spec requires: 'Refactoring-Environment' ];

Do you know if this is correct?
And why?

Stef

I saw that

selectionIntervalFor:

        uses

selectionParseTreeIntervalFor: aString
        | parseTree answerBlock |
        parseTree := RBParser
                parseMethod: aString
                onError: [ :str :pos | ^ nil ].
        answerBlock := [ :aNode :answer | ^ aNode sourceInterval ].
        self searchStrings do: [ :each |
                | matcher tree |
                matcher := RBParseTreeSearcher new.
                matcher matchesTree: (RBLiteralNode value: each) do: answerBlock.
                each isSymbol
                        ifTrue: [
                                tree := RBParseTreeSearcher buildSelectorTree: each.
                                tree notNil ifTrue: [ matcher matchesTree: tree do: answerBlock ] ]
                        ifFalse: [
                                tree := RBVariableNode named: each.
                                matcher
                                        matchesTree: tree do: answerBlock;
                                        matchesArgumentTree: tree do: answerBlock ].
                matcher executeTree: parseTree ].
        ^ nil

and I was wondering where is used the selectionIntervalFor:

Then I saw that BrowserEnvironmentWrapper introduces environment (which is good)

Now the superclass uses directly Smalltalk globals so may be this would be good to move enviroment above
this way we can have a selection of the environemt as in BrowserEnvironment and also have a browser that can browse a remote
environment.

Stef

> and I was wondering where is used the selectionIntervalFor:

To accurately highlight matches (senders, implementers, parse tree
matches, lint issues) in the tools.

> Then I saw that BrowserEnvironmentWrapper introduces environment (which is good)

'BrowserEnvironment' implements a composite pattern. The variable
'environment' refers to another 'BrowserEnvironment' instance, not to
a 'SystemDictionary'.

> Now the superclass uses directly Smalltalk globals so may be this would be good to move enviroment above
> this way we can have a selection of the environemt as in BrowserEnvironment

No, BrowserEnvironment represents the system. In a system with
multiple namespaces it represents a merged view of all the classes in
the complete system no matter what namespace they are in. If we had
namespaces a new subclass (NamespaceEnvironment) could provide a view
onto a particular namespace, just like the PackageEnvironment does
today.

>  also have a browser that can browse a remote environment.

This was once possible, but since Class/Metaclass/SmalltalkDictionary
moved so far away from RBClass/RBMetaclass/BrowserEnvironment (they
were once polymorphic) it is very hard to do anything that works on
different models.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

On Mar 17, 2011, at 7:05 PM, Lukas Renggli wrote:

>> and I was wondering where is used the selectionIntervalFor:
>
> To accurately highlight matches (senders, implementers, parse tree
> matches, lint issues) in the tools.

so this could be packaged separated so that we can use the environment without having to have the AST-core + parser loaded.
In our version we will separate that. When AST-Core will be the default AST the problem will be less important.

but why not having
environment = a parametrizing namespace in the browser environment this way we avoid all the
Smalltalk globals everywhere and suddenly we can use the same environment to browse remote images
and have currentSelectionEnvironment = the composite. I do not see why Wrapper is needed.

>> also have a browser that can browse a remote environment.
>
> This was once possible, but since Class/Metaclass/SmalltalkDictionary
> moved so far away from RBClass/RBMetaclass/BrowserEnvironment (they
> were once polymorphic) it is very hard to do anything that works on
> different models.

We will fix. I think that we will clone the code and see what we can do.

Stef