BTW lukas I'm not angry at you :). I will look at your point and see how we can fix them. I just need this behavior. I have been fixing SystemNavigation (which should be also rewritten or replace), next the compiler should be parametrized and also the test runner logic and probably MC and at the end we will have a system that can do what I need. Stef On Mar 18, 2011, at 10:09 PM, Lukas Renggli wrote:
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.
You clearly break the following methods and potentially all 55 references to BrowserEnvironment:
- BrowserEnvironment>>#copyEmpty - BrowserEnvironment>>#& - BrowserEnvironment>>#I - BrowserEnvironment>>#not - BrowserEnvironment>>#isSystem - ClassEnvironment>>#classesDo: - SelectorEnvironment>>#classesDo:
Not sure how you are going to meaningfully fix these when BrowserEnvironment can point to different environments?
I can only repeat myself: BrowserEnvironment encapsulates the complete system (world). All that you can potentially see within a given image at a given time. If you have Pharo 1.2 and Pharo 1.3 in your image then BrowserEnvironment would enumerate Object from Pharo 1.2 and Object from Pharo 1.3.
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.
I don't know why you get angry? I am just telling you how John Brant and Don Roberts implemented the system. Just fundamentally changing core classes of a framework without understanding the implications doesn't help. If you don't believe me ask John or compare the code with the one in VisualWorks where you could actually have different system versions at the same time in the image.
So again: If you want a view onto your namespace create a BrowserEnvironmentWrapper subclass that holds a reference to your namespace like PackageEnvironment with its package. That is how it is ment to be done.
Lukas
-- Lukas Renggli www.lukas-renggli.ch