[squeak-dev] SmalltalkImage semi-self-references

H. Hirzel hannes.hirzel at gmail.com
Sat Jul 20 21:47:43 UTC 2013


On 7/20/13, David T. Lewis <lewis at mail.msen.com> wrote:
> 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.
+1

 The notion of a current VM also makes sense (we restart our
> images on different VMs that have different capabilities).

+1

 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).

+1



> Dave
>
>
>


More information about the Squeak-dev mailing list