<div dir="ltr"><div><div><div><div><div>Currently, SmalltalkImage current == Smalltalk.<br>SmalltalkImage current should not be used anymore, but should rather be replaced with Smalltalk<br>(we did not change the too many senders, maybe this was not the best decision).<br>
<br></div>As Tim said, since the SystemDictionary was bloated with many system utilities, we turned it the other way around: let Smalltalk be a reflection of the system, and separate the SystemDictionary to Smalltalk globals.<br>
Note that Smalltalk globals printString used to answer 'Smalltalk globals', but it was changed since Environment, it now incorrectly answers 'Smalltalk' which is not an environment...<br><br>Now whether Smalltalk should be self from within SmalltalkImage, I'd
rather say yes, but it makes sense if ever there is another
SmalltalkImage.<br> Of course, all this was pre-Environment, so it might continue to evolve.<br><br></div><div>If we want to reify a VM object, then we would probably access the currently used one through Smalltalk vm (and currently, it answers self, because SmalltalkImage reflects the whole system).<br>
Same for operating system, see Smalltalk os...<br></div><div><br></div>SystemNavigation provides low level system reflection capabilities (all implementors of, etc...) + higher level UI requests.<br></div>It looks like we could give it more care, because it uses ToolSet for most UI requests, and has 2 unused instance variables for determining browser class.<br>
</div>Whether it should be re-integrated to Smalltalk (TheSystem) or not, I don't know, but what I wonder about is what should be the proper tools to handle environments. Should we restrict the browsing to a specific Environment (see SystemNavigation for: anEnvironment), or should we offer cross-environments capabilities?<br>
</div>It all depends what we use environment for. Maybe we will need some kind of sub system, a system in the system...<br> </div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/20 David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sat, Jul 20, 2013 at 10:09:01AM -0700, tim Rowledge wrote:<br>
><br>
> On 20-07-2013, at 9:36 AM, Bob Arning <<a href="mailto:arning315@comcast.net">arning315@comcast.net</a>> wrote:<br>
><br>
> > When I see longer ways of saying something replacing shorter ways, I always wonder if the perceived benefit has been realized. Are there success stories out there for "SmalltalkImage current" enabling something cool that "Smalltalk" could not?<br>
><br>
<br>
</div>None that I am aware of.<br>
<div class="im"><br>
> IIRC the original idea was that SystemDictionary was overloaded with nothing-to-do-with-dictionary methods and needed to go on a diet. I don't recall it being suggested that the smarter thing would have been to remove the *dictionary* stuff and put that somewhere else to use as an environment for compiling, leaving the useful system management methods attached to something called 'Smalltalk'. I really don't like the current (sic) setup where there is SmalltalkImage SystemNavigation and Smalltalk and probably other split out stuff I haven't even found.<br>
><br>
> Time for re-unification.<br>
><br>
<br>
</div>Yes. Some if this is half-finished work that probably falls under the category<br>
of what Andreas rather uncharitably (but accurately) referred to as "random<br>
refactorings" from the Squeak 3.9 era. From my point of view, it was stuff<br>
being shuffled about for the sake of moving it around, but without a coherent<br>
conceptual basis for the "improvements".<br>
<br>
Having said that, I do think that allowing "Smalltalk" to become a dumping<br>
ground for otherwise homeless methods is not a very good idea either, so some<br>
amount of refactoring is in order. And I think that it is a good thing to have<br>
some conceptual separation between things that are associated with the Smalltalk<br>
environment itself, versus things that are associated with the virtual machine<br>
(capabilities or lack thereof in the supporting VM), versus things that are<br>
associated with the underlying platform (operating system, file systems,<br>
and so forth).<br>
<br>
I have not really wrapped my head around Environments yet, but I'm pretty<br>
sure that this is a very good thing, and that it will help to clarify things<br>
conceptually. So this seems to be a good time to rethink some of the earlier<br>
mis-factorings and put them into a more clearly defined context. So, for<br>
example, the notion of a "current Smalltalk image" seems like complete<br>
nonsense to me, but the the notion of a current Environment might make a<br>
lot of sense. The notion of a current VM also makes sense (we restart our<br>
images on different VMs that have different capabilities). And it probably<br>
makes sense to have something that represents the current operating system<br>
platform (the "same" VM might be running on different operating systems<br>
and/or different file systems).<br>
<br>
Dave<br>
<br>
<br>
</blockquote></div><br></div>