2015-08-20 11:51 GMT+02:00 Dimitris Chloupis <kilon.alios@gmail.com>:

I took a look at the class you recommended and now I see what you mean.I am glad this is not deeply tied to the system browser and is something other tools can use as well with ease. Very flexible too. Looks like the tools only expose a fraction of the power of the environment .

Well, behind all things RB (the Refactoring Browser[1]) you have a complete model of Smalltalk code. It allows refactoring tools to work on live code but also on non-live code. For example, in SmaCC, which is implemented by the same guys, the code for a parser is generated entirely as refactorings (i.e. non-live code), then refactored for optimisations for both code performance and to minimize the number of refactorings (but still non-live), then split to fit the Cog Jit limits (my work!), and then compiled to the live system in one (large) step.

But why am I saying that? To show that those environments are very flexible (and the tools around as well), that they may work on non-live code (for example, a non-loaded package) and that most of the IDE needed functions in practice apply on a model linked to the live code, including when using them through Nautilus.

[1]��http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.9246&rep=rep1&type=pdf

Makes me wonder whether environment would be a good idea to be used as some sort of namespaces.��

The difference between an environment and a namespace is at the compiler level: can you make the compiler use an environment when compiling a method? I think that Marcus has done things in that direction recently (such as allowing you to add "virtual" instance variables before compiling a method). Also an environment never "renames" stuff, it only "restricts" what is visible.

At the programmer level, a Namespace is the ability to have two pieces of code where the class named Morph is an entirely different class, and that you can't understand the code anymore because you're never sure of what a global refers to (since it may be renamed via an import statement)... Some will say it's a feature ;)

Thierry

��

On Thu, Aug 20, 2015 at 9:08 AM Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 19/08/2015 20:26, Dimitris Chloupis a ��crit :
>
>
> On Wed, Aug 19, 2015 at 5:51 PM Sean P. DeNigris <sean@clipperadams.com
> <mailto:sean@clipperadams.com>> wrote:
>
>�� kilon.alios wrote
>
>
>�� For example, let's say your project has a class that implements a
>�� generically-named method, like #asMorph. If you try to rename that
>�� method
>�� via Refactoring, Pharo will try to rename all #asMorph methods, and
>�� update
>�� all senders, in the entire system, not just yours. But if you scope the
>�� browser first to your package or class, you can restrict the
>�� environment to
>�� which the refactoring is applied
>
>
> This sounds useful indeed. Is just the browser aware of the scope or is
> also the pharo environment aware of the scope too ? It would be nice if
> the scope could expand to include multiple�� packages , or is this
> something left to groups ?

What is happening is that many commands linked to the IDE (refactorings,
searches) have an environment entity. By default, this environment is
Smalltalk, but it can be a subset of it, and any subset of it.

Have a look into the RBBrowserEnvironment class and subclasses and you
will see all the variants. For example, a RBPackageEnvironment will
scope to one or multiple packages.

Thierry