<div dir="ltr"><div><div><div><div>Did you read this answer of Andreas to my plan B?<br><br>In other words, there needs to be a very clearly cut line: If you need
<br>compatibility, you use e.g., Smalltalk allClasses, Smalltalk
<br>vmParameters, Smalltalk garbageCollect. If you don't, you're free to use
<br>Namespace default allClasses or VirtualMachine current parameters or
<br>System soleInstance garbageCollect or Smalltalk vm parameters or
<br>Smalltalk namespace allClasses. All of these can be delegated trivially
<br>to from the Smalltalk facade making it very easy to provide the
<br>necessary level of compatibility while leaving room for innovation.
<br><br></div><div>Since Smalltalk is SmalltalkImage current, you don't need to preoccupate anymore, just write Smalltalk, it's all for compatibility.<br></div><div>That's what I meant by saying that Cuis compatibility was just a few messages away.<br>
</div><div><br></div></div>So maybe it's some of the messages of Smalltalk class methodDictionary that you don't like?<br></div><div>There probably is a bit of cruft that have not been cleaned up, but that's how you buy compatibility...<br>
With an extreme point of view, empty is clean ;)<br>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.<br></div><div><br></div>
<div>Note that SmalltalkImage is not a Pharoism, though pushed by creators of Pharo. It's from Squeak 3.9.<br>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.<br>
<br>Anyway, whether this cruft is implemented in SmalltalkImage current or in SystemDictionary should hardly be a problem right?</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/21 Casey Ransberger <span dir="ltr"><<a href="mailto:casey.obrien.r@gmail.com" target="_blank">casey.obrien.r@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF"><div>Inline<div class="im"><br><br>On Jul 21, 2013, at 2:01 PM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
<br></div></div><div class="im"><div></div><blockquote type="cite"><div><div dir="ltr"><div><div>You mean bring back so called Plan-A from <a href="http://forum.world.st/SmalltalkImage-current-vs-Smalltalk-plan-B-tt1577429.html#none" target="_blank">http://forum.world.st/SmalltalkImage-current-vs-Smalltalk-plan-B-tt1577429.html#none</a><br>
</div>You'll have to read the whole thread for pros and cons.<br></div>The funny thing is that Cuis compatibility might just consists in a few messages..</div></div></blockquote><div><br></div></div><div>A few messages and actually wanting this junk in my nice clean image, yes;)</div>
<div><br></div><div>I hate saying that because I know someone put their heart into these changes, but I don't really want them. </div><div><br></div><div>For all I know though, it's already in Cuis. I haven't tried porting anything for awhile. </div>
<div><div class="h5"><br><blockquote type="cite"><div><div class="gmail_extra"><div class="gmail_quote">
2013/7/21 Casey Ransberger <span dir="ltr"><<a href="mailto:casey.obrien.r@gmail.com" target="_blank">casey.obrien.r@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi folks,<br>
<br>
IIRC there was a long discussion about SmalltalkImage current.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<div><div><br>
On Jul 20, 2013, at 1:10 PM, "David T. Lewis" <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br>
<br>
> On Sat, Jul 20, 2013 at 10:09:01AM -0700, tim Rowledge wrote:<br>
>><br>
>> On 20-07-2013, at 9:36 AM, Bob Arning <<a href="mailto:arning315@comcast.net" target="_blank">arning315@comcast.net</a>> wrote:<br>
>><br>
>>> 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?<br>
>><br>
><br>
> None that I am aware of.<br>
><br>
>> 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.<br>
>><br>
>> Time for re-unification.<br>
>><br>
><br>
> Yes. Some if this is half-finished work that probably falls under the category<br>
> of what Andreas rather uncharitably (but accurately) referred to as "random<br>
> refactorings" from the Squeak 3.9 era. From my point of view, it was stuff<br>
> being shuffled about for the sake of moving it around, but without a coherent<br>
> conceptual basis for the "improvements".<br>
><br>
> Having said that, I do think that allowing "Smalltalk" to become a dumping<br>
> ground for otherwise homeless methods is not a very good idea either, so some<br>
> amount of refactoring is in order. And I think that it is a good thing to have<br>
> some conceptual separation between things that are associated with the Smalltalk<br>
> environment itself, versus things that are associated with the virtual machine<br>
> (capabilities or lack thereof in the supporting VM), versus things that are<br>
> associated with the underlying platform (operating system, file systems,<br>
> and so forth).<br>
><br>
> I have not really wrapped my head around Environments yet, but I'm pretty<br>
> sure that this is a very good thing, and that it will help to clarify things<br>
> conceptually. So this seems to be a good time to rethink some of the earlier<br>
> mis-factorings and put them into a more clearly defined context. So, for<br>
> example, the notion of a "current Smalltalk image" seems like complete<br>
> nonsense to me, but the the notion of a current Environment might make a<br>
> lot of sense. The notion of a current VM also makes sense (we restart our<br>
> images on different VMs that have different capabilities). And it probably<br>
> makes sense to have something that represents the current operating system<br>
> platform (the "same" VM might be running on different operating systems<br>
> and/or different file systems).<br>
><br>
> Dave<br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span></span><br></div></blockquote></div></div></div><br><br>
<br></blockquote></div><br></div>