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.

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.
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100302/ef8b7455/attachment.htm