[squeak-dev] SmalltalkImage semi-self-references
casey.obrien.r at gmail.com
Sun Jul 21 20:38:05 UTC 2013
IIRC there was a long discussion about SmalltalkImage current.
I believe the current state of affairs (pun intended) arose because they did this SmalltalkImage thing in Pharo, and folks wanted to be code compatible without having to actually take the changes from Pharo, which some people had objections to.
I don't remember what the objections were, but I do think I remember a general theme of "this is an unnecessary refactoring." I think Andreas sort of begrudgingly checked it in.
I noticed this a lot because it's a Pharoism that I had to rip out of applications when porting them from either dialect to Cuis.
While it would make us less compatible with Pharo, I think we should just rip this out. Move it to an external Pharo-Compat package somehow or something.
That's my two cents. To me Smalltalk is a representative of the object memory *and* the VM *and* the interactive development environment, because when I read the Blue Book, I finished with the view that Smalltalk is comprised of these three things. But that's just epistemological, and I guess practical concerns sometimes displace thoughts about thinking.
On Jul 20, 2013, at 1:10 PM, "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. 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).
More information about the Squeak-dev