Goran,

> Ok, here we go. This is simple:

Short answer: I'll take it. It's simple, clear, leaves the responsibilities
in the right places. In short, this is precisely what I was hoping for.

Thanks,
  - Andreas

>
> 1. Instead of ONE big Smalltalk dictionary we introduce a new class
> called Namespace. It is much like a Dictionary and we create instances
> of it and put them in Smalltalk. This will probably mostly be done
> automatically for you by the tools, but anyway. So looking up a
> qualified name "Foo::Bar" manually can be done like this:
>
> value := (Smalltalk at: #Foo) at: #Bar
>
> 2. Every class belongs to a Namespace. A class knows its Namespace
> simply by its name, which is the qualified name. We simply rename all
> classes to qualified names. So the class Delay will from now on be named
> Kernel::Delay (depending on what Namespaces we come up with of course,
> but I am thinking of pretty few for the standard image, Morphic is one,
> Kernel is another etc).
>
> 3. The above means that ALL classes in the image are still additionally
> available just like before in Smalltalk, this has many big advantages I
> think:
> (Smalltalk at: #Kernel::Delay) == ((Smalltalk at: #Kernel) at: #Delay)
>
> 4. The source for the methods will *always* have the fully qualified
> names, like "Kernel::Delay". The source *displayed* in the browsers and
> the source *accepted* in the browsers may in some circumstances be able
> to use unqualified names, like "Delay". BUT... (and this is important)
> it is the tools that decide how code is displayed and accepted and they
> will do it by providing a LookupContext object to the Compiler. When the
> Compiler sees "Delay" it will consult the LookupContext object in order
> to resolve it into a qualified name. And when the browsers display code
> they will also consult the LookupContext object to decide if the
> qualified names can actually be displayed unqualified without disturbing
> the user. This is a very important piece of the puzzle because it
> removes the reason for having imports - not having to read and write
> silly long qualified names in 99% of the case.
>
>
> Ok, the above 4 points more or less describe my proposal if we leave out
> the tool side of it - the LookupContext. That part is very important -
> but I am trying to keep it short here.
>
> I want to come up with a good default implementation of LookupContext
> that we can use for the "standard Squeak" tool set. I have described it
> in earlier postings. But Andreas is free to make his own implementation
> for other environments like Croquet or Tweak.
>
> My proposal for the standard LookupContext makes it use and accept the
> unqualified names as often as possible. So this means that 99% of Squeak
> will still look just like it does today. No really big changes on the
> surface since all class names are already unique.
>
> I am also leaving out the "shy" concept here - not that I don't think it
> is needed - but I want to stay focused on the 4 important parts. Note
> above that Namespaces are flat - there are no imports etc. Quite simple
> and it will keep the Squeaky feeling as much as possible I think.
>
> regards, Göran
>