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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Mar 2 21:07:33 UTC 2010


2010/3/2 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> 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)?

Agree, 99%
For the remaining 1%, my thought was that Browser could become an
abstract factory instead of a Specific tool.
The specific tools would be renamed SystemBrowser (or HierarchyBrowser
OBBrowser WhiskerBrowser etc...).

Nicolas

>>
>>  > 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.

Don't apply that on Squeak now, we gonna feel naked ;)

>>
>> > 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.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> >
>> >
>>
>
>
>
>
>



More information about the Squeak-dev mailing list