<br><br><div class="gmail_quote">On Tue, Mar 2, 2010 at 12:03 PM, Nicolas Cellier <span dir="ltr">&lt;<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2010/3/2 Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>&gt;:<br>
<div><div></div><div class="h5">&gt;<br>
&gt;<br>
&gt; On Tue, Mar 2, 2010 at 3:08 AM, keith &lt;<a href="mailto:keith_hodges@yahoo.co.uk">keith_hodges@yahoo.co.uk</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; 1) The Cuis variant: Move all the code back to SystemDictionary; implement<br>
&gt;&gt; SmalltalkImage current as ^Smalltalk.<br>
&gt;&gt;<br>
&gt;&gt; Cuis didn&#39;t exactly move the code back to SystemDictionary, of course it<br>
&gt;&gt; never left in the first place. It is easier for Cuis to implement<br>
&gt;&gt; compatibility with &quot;trunk&quot; than it is for &quot;trunk&quot; to go back to the old way.<br>
&gt;&gt; How much code uses Smalltalk at: ? As soon as you put SmalltalkImage<br>
&gt;&gt; current into Smalltalk you have to make what was an &quot;image utilities&quot; class<br>
&gt;&gt; behave like a dictionary.<br>
&gt;&gt; You seem to be saying, we must have a single place to access this stuff<br>
&gt;&gt; called &quot;Smalltalk&quot;. I think what really needs to happen is to factor things<br>
&gt;&gt; up nicely and logically so we know where to find things and can write<br>
&gt;&gt; compatible code.<br>
&gt;&gt; I propose as a starting point, that we design a scheme or convention that<br>
&gt;&gt; implements the &quot;long hand&quot; variant, and then when happy with this, implement<br>
&gt;&gt; the short hand versions. The most obvious long hand variant.<br>
&gt;&gt; self class environment &quot;system globals&quot;<br>
&gt;&gt; self class environment image<br>
&gt;&gt; self class environment navigation<br>
&gt;&gt; self class environment sourceFiles<br>
&gt;&gt; self class environment startupManager.<br>
&gt;&gt; self class environment organization.<br>
&gt;<br>
&gt; This doesn&#39;t make sense in a workspace where the notion of the current class<br>
&gt; is a weak one (current class is UndefinedObject for want of having no class<br>
&gt; at all).<br>
&gt; Why are global names worse than any of these?<br>
&gt; I think Smalltalk == System is a good approach.  Making things verbose is a<br>
&gt; very poor direction.  When a cluster of associated behaviours gets complex<br>
&gt; enough then by all means move it out to a class.  So in VisualWorks the<br>
&gt; pairing of ObjectMemory and MemoryPolicy which allows inspection and<br>
&gt; tailoring of memory management makes sense.<br>
&gt; A Tools object for systemNavigation might make sense, but SystemNavigation<br>
&gt; is a poor name; long (SystemNavigation default being worse) and not very<br>
&gt; informative.  BrowserQuery would be better.  Browse would be better.<br>
<br>
</div></div>Maybe a SystemNavigation was introduced to handle the fact that there<br>
were many different browsers... Or Morphic + MVC....<br>
Maybe some were thinking embedding a default + some alternatives in a<br>
single image...<br></blockquote><div><br></div><div>Maybe, but if that effort wasn&#39;t implemented it wass pointless.  Introducing the abstraction without adding it is pointless.  For example, using traits only in the traits implementation, instead of where it belongs, the collection hierarchy, is pointless.</div>
<div><br></div><div>But I&#39;m not criticising the idea of SystemNavigation, only its naming.  There&#39;s clear benefit to having something with SystemNavigation functionality, but SystemNavigation is a poor name.  Browse is a better name.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
(Browser browseAllCallsOn: #yourself) was just perfectly short :)<br>
Or (Browser allCallsOn: #yourself) open/view/edit/browse/..., if we<br>
really want to avoid pairing each message.<br>
A pity that Browser itself failed to become the abstract factory which<br>
SystemNavigation default is...<br></blockquote><div><br></div><div>Yes, but Browser is a specific tool and it makes sense when there are many different browsers to separate the request to open a browser from the browser itself.  Also, queries which answer sets of MethodReferences et al are very useful and don&#39;t necessarily belong in Browser.  So why not Browse and Browser for the request and one of its results?  Is SystemNavigation default a good name?  Does the default in SystemNavigation default provide anything useful (e.g. that preferences don&#39;t)?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
 &gt; The worst thing going on with things like SmalltalkImage current,<br>
&gt; SystemNavigation default and traits is the introduction of abstraction for<br>
&gt; its own sake.  Abstraction is properly used to manage complexity.  But for<br>
&gt; example, as others have pointed out, there is no other image than the<br>
&gt; current image and so SmalltalkImage current is merely verbiage.  And yet<br>
&gt; SourceFiles is an obvious area which could use a lot more features (being<br>
&gt; able to load package sources without appending them to the sources file, or<br>
&gt; having two changes files, one for loaded packages, one for user<br>
&gt; modifications, etc).<br></div></div></blockquote><div><br></div><div>I meant to emphasise here that traits is a perfect example of not going far enough to justify its existence.  Traits are a great idea but unless they&#39;re carried through and used in implementing class libraries other than the traits system itself (i.e. especially the collection hierarchy) they&#39;re overhead that is carried in lots of places (cognitive complexity for new users, complexity in the tools, e.g. Monticello, etc).  I&#39;m not saying get rid of traits.  I&#39;m saying that something shouldn&#39;t become a component of the core until it carries its weight (much as in PARC the contents of the base image were discussed every 6 months in a sort of balloon game with components that couldn&#39;t be defended being ejected) and we shouldn&#39;t repeat the mistake of integrating half-completed abstractions.  When introducing new abstractions during decomposition be sure that the effort is worth it and that the implementation is carried through.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">
&gt; Another bad thing is not thinking about names.  Names are extremely<br>
&gt; important for making sense of a system, most especially for new users.<br>
&gt;  Finding a vivid short name is well worth extra effort.<br>
&gt; I&#39;d love to see someone start a side project which comprised<br>
&gt; - a minimal kernel image, capable of bootstrapping (so includes base class<br>
&gt; library, compiler, gui-less debugger/back-tracer, file system interface)<br>
&gt; - a set of packages comprising loadable programming tools<br>
&gt; - a refactoring engine and rules base for converting from the current Squeak<br>
&gt; dialects where the rules were renamings of things like &quot;SystemNavigation<br>
&gt; default&quot; into &quot;Browse&quot;<br>
&gt; and which focussed on a new set of global names for the environment.  The<br>
&gt; base class library would stay the same, but Smalltalk, SystemNavigation,<br>
&gt; SmalltalkImage etc would be up for grabs.<br>
&gt; I&#39;d then love to see a university department divide a class into two and see<br>
&gt; how each set of students faired with each variant, each provided with<br>
&gt; otherwise identical introductory material that differed only in the names &amp;<br>
&gt; organization of these system services classes.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; For the shorter hand variants, personally I wouldn&#39;t mind these being<br>
&gt;&gt; implemented on Object, aka #systemNavigation.<br>
&gt;&gt; self systemEnvironment, self systemImage, self systemNavigation, self<br>
&gt;&gt; systemSourceFiles, self systemStartupManager, self systemOrganization<br>
&gt;&gt; but I think I would prefer an instance side implementation of<br>
&gt;&gt; #environment/#system/#smalltalk<br>
&gt;&gt; SmalltalkImage current would then become:<br>
&gt;&gt; self environment image / self smalltalk image.<br>
&gt;&gt; ok, it&#39;s not compatible, but its not a mess either.<br>
&gt;&gt; The compatibility I would fix temporarily with better code loading tools,<br>
&gt;&gt; or a dnu: on SystemDictionary.<br>
&gt;&gt; K.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
</div></div></blockquote></div><br>