[squeak-dev] Re: SmalltalkImage current vs. Smalltalk

Eliot Miranda eliot.miranda at gmail.com
Tue Mar 2 20:41:35 UTC 2010


On Tue, Mar 2, 2010 at 12:03 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> 2010/3/2 Eliot Miranda <eliot.miranda at gmail.com>:
> >
> >
> > On Tue, Mar 2, 2010 at 3:08 AM, keith <keith_hodges at yahoo.co.uk> wrote:
> >>
> >> 1) The Cuis variant: Move all the code back to SystemDictionary;
> implement
> >> SmalltalkImage current as ^Smalltalk.
> >>
> >> Cuis didn't exactly move the code back to SystemDictionary, of course it
> >> never left in the first place. It is easier for Cuis to implement
> >> compatibility with "trunk" than it is for "trunk" to go back to the old
> way.
> >> How much code uses Smalltalk at: ? As soon as you put SmalltalkImage
> >> current into Smalltalk you have to make what was an "image utilities"
> class
> >> behave like a dictionary.
> >> You seem to be saying, we must have a single place to access this stuff
> >> called "Smalltalk". I think what really needs to happen is to factor
> things
> >> up nicely and logically so we know where to find things and can write
> >> compatible code.
> >> I propose as a starting point, that we design a scheme or convention
> that
> >> implements the "long hand" variant, and then when happy with this,
> implement
> >> the short hand versions. The most obvious long hand variant.
> >> self class environment "system globals"
> >> self class environment image
> >> self class environment navigation
> >> self class environment sourceFiles
> >> self class environment startupManager.
> >> self class environment organization.
> >
> > This doesn't make sense in a workspace where the notion of the current
> class
> > is a weak one (current class is UndefinedObject for want of having no
> class
> > at all).
> > Why are global names worse than any of these?
> > I think Smalltalk == System is a good approach.  Making things verbose is
> a
> > very poor direction.  When a cluster of associated behaviours gets
> complex
> > enough then by all means move it out to a class.  So in VisualWorks the
> > pairing of ObjectMemory and MemoryPolicy which allows inspection and
> > tailoring of memory management makes sense.
> > A Tools object for systemNavigation might make sense, but
> SystemNavigation
> > is a poor name; long (SystemNavigation default being worse) and not very
> > informative.  BrowserQuery would be better.  Browse would be better.
>
> Maybe a SystemNavigation was introduced to handle the fact that there
> were many different browsers... Or Morphic + MVC....
> Maybe some were thinking embedding a default + some alternatives in a
> single image...
>

Maybe, but if that effort wasn'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.

But I'm not criticising the idea of SystemNavigation, only its naming.
 There's clear benefit to having something with SystemNavigation
functionality, but SystemNavigation is a poor name.  Browse is a better
name.

>
> (Browser browseAllCallsOn: #yourself) was just perfectly short :)
> Or (Browser allCallsOn: #yourself) open/view/edit/browse/..., if we
> really want to avoid pairing each message.
> A pity that Browser itself failed to become the abstract factory which
> SystemNavigation default is...
>

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'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't)?


>  > The worst thing going on with things like SmalltalkImage current,
> > SystemNavigation default and traits is the introduction of abstraction
> for
> > its own sake.  Abstraction is properly used to manage complexity.  But
> for
> > example, as others have pointed out, there is no other image than the
> > current image and so SmalltalkImage current is merely verbiage.  And yet
> > SourceFiles is an obvious area which could use a lot more features (being
> > able to load package sources without appending them to the sources file,
> or
> > having two changes files, one for loaded packages, one for user
> > modifications, etc).
>

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're
carried through and used in implementing class libraries other than the
traits system itself (i.e. especially the collection hierarchy) they're
overhead that is carried in lots of places (cognitive complexity for new
users, complexity in the tools, e.g. Monticello, etc).  I'm not saying get
rid of traits.  I'm saying that something shouldn'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't be defended being ejected) and we shouldn'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.

> Another bad thing is not thinking about names.  Names are extremely
> > important for making sense of a system, most especially for new users.
> >  Finding a vivid short name is well worth extra effort.
> > I'd love to see someone start a side project which comprised
> > - a minimal kernel image, capable of bootstrapping (so includes base
> class
> > library, compiler, gui-less debugger/back-tracer, file system interface)
> > - a set of packages comprising loadable programming tools
> > - a refactoring engine and rules base for converting from the current
> Squeak
> > dialects where the rules were renamings of things like "SystemNavigation
> > default" into "Browse"
> > and which focussed on a new set of global names for the environment.  The
> > base class library would stay the same, but Smalltalk, SystemNavigation,
> > SmalltalkImage etc would be up for grabs.
> > I'd then love to see a university department divide a class into two and
> see
> > how each set of students faired with each variant, each provided with
> > otherwise identical introductory material that differed only in the names
> &
> > organization of these system services classes.
> >
> >>
> >> For the shorter hand variants, personally I wouldn't mind these being
> >> implemented on Object, aka #systemNavigation.
> >> self systemEnvironment, self systemImage, self systemNavigation, self
> >> systemSourceFiles, self systemStartupManager, self systemOrganization
> >> but I think I would prefer an instance side implementation of
> >> #environment/#system/#smalltalk
> >> SmalltalkImage current would then become:
> >> self environment image / self smalltalk image.
> >> ok, it's not compatible, but its not a mess either.
> >> The compatibility I would fix temporarily with better code loading
> tools,
> >> or a dnu: on SystemDictionary.
> >> K.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100302/8096a39d/attachment.htm


More information about the Squeak-dev mailing list