[squeak-dev] SmalltalkImage semi-self-references
nicolas.cellier.aka.nice at gmail.com
Sun Jul 21 22:26:17 UTC 2013
Did you read this answer of Andreas to my plan B?
In other words, there needs to be a very clearly cut line: If you need
compatibility, you use e.g., Smalltalk allClasses, Smalltalk
vmParameters, Smalltalk garbageCollect. If you don't, you're free to use
Namespace default allClasses or VirtualMachine current parameters or
System soleInstance garbageCollect or Smalltalk vm parameters or
Smalltalk namespace allClasses. All of these can be delegated trivially
to from the Smalltalk facade making it very easy to provide the
necessary level of compatibility while leaving room for innovation.
Since Smalltalk is SmalltalkImage current, you don't need to preoccupate
anymore, just write Smalltalk, it's all for compatibility.
That's what I meant by saying that Cuis compatibility was just a few
So maybe it's some of the messages of Smalltalk class methodDictionary that
you don't like?
There probably is a bit of cruft that have not been cleaned up, but that's
how you buy compatibility...
With an extreme point of view, empty is clean ;)
If you badly need to import packages in Cuis, then nothing prevents you to
add a Squeak-Compatibility layer (or Pharo), and let Cuis itself clean.
Note that SmalltalkImage is not a Pharoism, though pushed by creators of
Pharo. It's from Squeak 3.9.
Currently, the only message inserted in Squeak for Pharo compatibility are
Smalltalk vm, Smalltalk os, and maybe I forgot 1 or 2, that's not much
cruft. And we did not use them so far.
Anyway, whether this cruft is implemented in SmalltalkImage current or in
SystemDictionary should hardly be a problem right?
2013/7/21 Casey Ransberger <casey.obrien.r at gmail.com>
> On Jul 21, 2013, at 2:01 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
> You mean bring back so called Plan-A from
> You'll have to read the whole thread for pros and cons.
> The funny thing is that Cuis compatibility might just consists in a few
> A few messages and actually wanting this junk in my nice clean image, yes;)
> I hate saying that because I know someone put their heart into these
> changes, but I don't really want them.
> For all I know though, it's already in Cuis. I haven't tried porting
> anything for awhile.
> 2013/7/21 Casey Ransberger <casey.obrien.r at gmail.com>
>> Hi folks,
>> 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
>> 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>
>> > 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
>> > of what Andreas rather uncharitably (but accurately) referred to as
>> > refactorings" from the Squeak 3.9 era. From my point of view, it was
>> > being shuffled about for the sake of moving it around, but without a
>> > conceptual basis for the "improvements".
>> > Having said that, I do think that allowing "Smalltalk" to become a
>> > 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
>> > environment itself, versus things that are associated with the virtual
>> > (capabilities or lack thereof in the supporting VM), versus things that
>> > 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
>> > sure that this is a very good thing, and that it will help to clarify
>> > conceptually. So this seems to be a good time to rethink some of the
>> > 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
>> > images on different VMs that have different capabilities). And it
>> > makes sense to have something that represents the current operating
>> > platform (the "same" VM might be running on different operating systems
>> > and/or different file systems).
>> > Dave
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev