<div dir="ltr"><div><div><div><div><div>+1 for replacing SmalltalkImage current -> Smalltalk, we should have done that for long.<br></div>-1 for classifying SmalltalkImage in Kernel. SmalltalkImage is a reflection of the System and thus has its place in System.<br>
</div>SmalltalkImage is not absolutely necessary for the core (not like MethodDictionary, MethodContext, Class, Integer, ...).<br></div>What sort of dependency link would this simplify exactly?<br></div>+1 for using Smalltalk os -> OSPlatform (Pharo), Smalltalk organizer etc..., that was my plan B.<br>
I failed to convince Andreas on this one, Once bitten (by former SmalltalkImage split), twice shy, I guess.<br><br></div>Nicolas<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/24 Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 20 July 2013 18:09, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br>
><br>
> On 20-07-2013, at 9:36 AM, Bob Arning <<a href="mailto:arning315@comcast.net">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>
> 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>
</div>I'm actually in favour of _more_ splitting out. Having a one-stop-shop<br>
reference for all your everythings means loads of things referencing<br>
the one-stop shop. That makes modularity difficult.<br>
<br>
However, a possible resolution of the Tim vs Frank Paradox is to move<br>
SmalltalkImage into Kernel, and have other packages _extend_<br>
SmalltalkImage. Instead of "SystemNavigation default" you'd have<br>
"Smalltalk organizer", and so on.<br>
<br>
Having said that, we have bigger fish to fry. It's easy for us to<br>
bicker over the colour of the bikeshed, but we should really be<br>
spending our time beating on Environments and making the tools work<br>
correctly with same.<br>
<br>
So I'd just like to ask one thing. Is everyone happy with changing<br>
"SmalltalkImage current" references to "Smalltalk"? Doing so makes my<br>
job of decreasing coupling between packages much easier, because every<br>
SmalltalkImage reference I remove is one less dependency on<br>
System-Support. (It might also be more Environmentally friendly!)<br>
<span class="HOEnZb"><font color="#888888"><br>
frank<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> tim<br>
> --<br>
> tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a><br>
> Klingon Code Warrior:- 6) "Our competitors are without honor!"<br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>