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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Mar 2 20:03:51 UTC 2010


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

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


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