On 21 July 2013 14:08, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> Currently, SmalltalkImage current == Smalltalk.
> SmalltalkImage current should not be used anymore, but should rather be
> replaced with Smalltalk
> (we did not change the too many senders, maybe this was not the best
> decision).

Well, I'm glad there's some discussion about other stuff, but in this
particular instance I don't care whether it's Smalltalk or
SmalltalkImage current. What I do care about is a bunch of code that
really looked like it should have been using self, instead of a
reference to some global. But I'm happy, now that I've fixed the
problem. So back to discussing SmalltalkImage current instead of
Smalltalk :)

frank

> 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.
> 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...
>
> Now whether Smalltalk should be self from within SmalltalkImage, I'd rather
> say yes, but it makes sense if ever there is another SmalltalkImage.
> Of course, all this was pre-Environment, so it might continue to evolve.
>
> 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).
> Same for operating system, see Smalltalk os...
>
> SystemNavigation provides low level system reflection capabilities (all
> implementors of, etc...) + higher level UI requests.
> 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.
> 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?
> It all depends what we use environment for. Maybe we will need some kind of
> sub system, a system in the system...
>
>
> 2013/7/20 David T. Lewis <lewis at mail.msen.com>
>
>> On Sat, Jul 20, 2013 at 10:09:01AM -0700, tim Rowledge wrote:
>> >
>> > On 20-07-2013, at 9:36 AM, Bob Arning <arning315 at comcast.net> wrote:
>> >
>> > > 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?
>> >
>>
>> None that I am aware of.
>>
>> > 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.
>> >
>> > Time for re-unification.
>> >
>>
>> Yes. Some if this is half-finished work that probably falls under the
>> category
>> of what Andreas rather uncharitably (but accurately) referred to as
>> "random
>> refactorings" from the Squeak 3.9 era. From my point of view, it was stuff
>> being shuffled about for the sake of moving it around, but without a
>> coherent
>> conceptual basis for the "improvements".
>>
>> Having said that, I do think that allowing "Smalltalk" to become a dumping
>> ground for otherwise homeless methods is not a very good idea either, so
>> some
>> amount of refactoring is in order. And I think that it is a good thing to
>> have
>> some conceptual separation between things that are associated with the
>> Smalltalk
>> environment itself, versus things that are associated with the virtual
>> machine
>> (capabilities or lack thereof in the supporting VM), versus things that
>> are
>> associated with the underlying platform (operating system, file systems,
>> and so forth).
>>
>> I have not really wrapped my head around Environments yet, but I'm pretty
>> sure that this is a very good thing, and that it will help to clarify
>> things
>> conceptually. So this seems to be a good time to rethink some of the
>> earlier
>> mis-factorings and put them into a more clearly defined context. So, for
>> example, the notion of a "current Smalltalk image" seems like complete
>> nonsense to me, but the the notion of a current Environment might make a
>> lot of sense. The notion of a current VM also makes sense (we restart our
>> images on different VMs that have different capabilities). And it probably
>> makes sense to have something that represents the current operating system
>> platform (the "same" VM might be running on different operating systems
>> and/or different file systems).
>>
>> Dave
>>
>>
>
>
>
>