On Mar 18, 2011, at 7:29 PM, Lukas Renggli wrote: > On 18 March 2011 18:39, Benjamin <[email protected]> wrote: >> Hi lukas >> >> with Stef we refactored the Browser environment: >> - now it can be parametrized by a system dictionary >> - we also move selectionIn* to the AST-Core so that Environment can >> be loaded independently. >> >> Could you integrate the packages in rb? > > No, please read the mail I sent this morning to the list. > > 1. 'BrowserEnvironment' is supposed to be *stateless*. > BrowserEnvironment is supposed to *always* represent exactly the same > thing.
Exaclty the environment we want to browse. When I import Pharo 1.3 in Moose running in Pharo 1.2 I want to be able to refer to the environment that contain Pharo 1.3 so I just pass this environment to the browser environment and all the others tools. I do not see why I would have to have another subclass. > The only refactoring that would make sense is to extract all > senders of 'Smalltalk globals' to a separate method so that subclasses > could override it. Why? Frankly you have so absolute statements. This is good to feel like idiots: "the only refactoring that makes sense" We are making ****ALL**** the tools environment aware: SystemNavigation, Compiler, TestRunner.... so why browserEnvironment would escape to the rule? We need that to be able to browse, compile other code than currently installed and we will do it. Why having a state is a problem? Sorry but we will use this version and we will probably introduce it in core. Because we want to have all the tool chain been able to work on a given environment. > > 2. The change where you move code from 'Refactoring-Enviornment' to > 'AST-Core' introduces a bad dependency. 'AST-Core' is at the lowest > level, it should not depend on anything else. Ideally the dependency > between 'Refactoring-Enviornment' to 'AST-Core' should be cut, but > that would involve a third package. In other Smalltalks the code in > question is packaged with the UI. Correct I did not pay attention, we will introduce a third package. Now if you do not like our changes we will fork. This is sad because we tried to make sure that RB could work on them but there is no problem we can fork also RB. Just let us know. Stef
