Hi martin

my first email could have been interpreted as rude so I erase it. My 
second reaction
was to ignore you but this was not polite, so the third will be to 
nicely reply to you :)


> We should avoid creating many new artificial classes too.

Exactly, but a class is more than a global, it is the place where we can
define, share abstraction and behavior.

> Look at it from the perspective of language ( as in human language
> which our brains speak when we program ): 'Smalltalk viewImageImports'
> makes sense, you are talking to your image and requesting information
> about it.

But you can talk to your imports too and ask them to show up visually.
No!?

> So you know where to look for such methods.
In Imports I have a better chance to find stuff related to imported 
objects
than to namespace whose the only responsibility should be dealing with
class names.

> OTOH no one will
> sift through all classes to find useable but hidden functionality in
> hidden classes like Xxx>>yyy ( you don't know the selector by then ).

There are several way to learn: sender, reference, class starting 
with.....
code of file list.

This is not because you find that Smalltalk should be trash where 
everybody
should put his convenient methods that this should be like that.

>
> One 'super' global like Smalltalk will make no problems at all:

Oh yes it does. Ask the guy that wanted to implement capabilities in 
Squeak
why he was forced to clean systemDictionary before been able to start.

> All
> possible images can contain this single one ( at least ? ) instance of
> SystemDictionary.

Yes because you need one root, but then you do not need to refer to it 
explicitly.
because you could have several namespace not even nested and your code 
could be moved from one to the other
in one click, while now Smalltalk is omnipresent and we cannot do 
anything besides breaking a lot.

>  To avoid references to Smalltalk - as you once
> demanded - gives you nothing, or am I missing here something ?

You are. If you want to introduce environment/namespace (like what dan 
started to do
if you look in the subclass of SystemDictionary) then all the 
references to Smalltalk
are a problem. While in fact this was plan in the original 
implementation of Smalltalk
that a class lives happily in its own environment (the message 
environment was there long long time ago)
this is just that people started to forget it because there was only 
one environment.

Ask the father of metaclasstalk he cleaned VisualWorks 2.5 before been 
able to implement his
language and reflective kernel.

> Instead
> it should help you to replace hard coded globals, which btw don't have
> to be problem in a well engineered module-system.
>
> SystemDictionary>>imageImports is right now only a lookup in the
> dictionary. Do you want to create a second dictionary which holds only
> imports ? If so, isn't this more complicated ? If not so, isn't it
> more complicated too to delegate the lookup to Smalltalk ?

No this is simple one class, a good interface and hop this is the place 
where people will be able
to hook a lot of stuff if they want to import stuff in the image. If 
Imports does not play his role
and is just the result of a need for eToy and people do not use it: 
perfect let us kill it.

I agree with Need the GraphicalDictionaryMenu is bad, does not scale 
when you have a lot of objects
and look ugly. So if you ask me I would remove it.

Stef

So I hope I replied well to your questions because it took energy and 
time.


> regards,
> Martin
>
>