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:
We will fix them. We forgot to look at BrowserEnvironement references. > 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. No it should not. And how about browsing remote images? This is exactly the same that SystemNavigation. Now systemNavigation works on an systemDictionary instance and of course if you work on two different ones you get something silly but else you can pass an systemDictionary instance and contextualize your queries. >> 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. Because you do not realize that your mails are often aggressive. Probably you are right in 80% of the case but consider that your mails can be perceived as aggressive. Trust lukas this is the way they can be read. I know you so I often succeed to take them easy but pay attention. > 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. I know. I understand the design of this code. Now it does not work with the scenario I have. I want to have an environment parametrized IDE which can work on different versions of the same system (pharo for example). I want to browse a remote environment that is given to me via proxy. I want to have the possibility to browser Hazelkernel separatedly from the rest and all these classes should not be in the same system dictionary instances. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >
