You mean bring back so called Plan-A from
http://forum.world.st/SmalltalkImage-current-vs-Smalltalk-plan-B-tt1577429.html#none
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
messages...


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
> 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).
> >
> > Dave
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130721/c22aa8e0/attachment.htm