Hi!

If you are interested in the proposal but has been lost in the thread -
read my recap below.

=?ISO-8859-1?Q?st=E9phane_ducasse?= <ducasse at iam.unibe.ch> wrote:
> Hi guys
> 
> Where are you going? I do not understand why you get all crazy about 
> that? Please do not create another monster.

I am trying to create a very simple solution! But it takes lots of
thinking to be simple - you know that. :)

> An import per class is pure nonsense. You do not want to have this 
> granularity. Imagine a symbol would means something different between 
> your class. Good luck. Look at VW this is wrong!!! YES wrong.

NOONE has argued for that I think. Well, maybe Lex - but I am giving him
the benefit of the doubt. :) I am even arguing for not having imports AT
ALL. 

> On 8 avr. 04, at 10:57, goran.krampe at bluefish.se wrote:
> 
> > If you are just talking about a different "way" to store the 
> > information
> > - I agree, might be easier, need to think a bit more about that. But it
> > sounds like you are instead describing an "import" model per class 
> > (just
> > like in Java), and that is different than what I describe.
> 
> Hopefully.
> 
> I did not read your proposal goran because I have too much work but 
> here is the summary I have from the discussion I got with andreas:
> 
> which is:
> 
> We need :: if we do not want to modify the environment
> Else we can an import at the namespace level.
> 
> I said:
> "Now the main difference between my view and the one of andreas
> (I understand well what he wants) is that we do not need :: ***if*** we 
> have a different
> environment. If we have an explicit import we do not need ::. This way
> we avoid that people can create worse spaghetti but we get namespace
> that is really only a collection of names with no magic.
> The price is to have another set of tools. So I understand that andreas
> did his choice. Alex reimplemented yet another browser. But my
> impression is that this is worth. Because having explicit scope
> operator can introduce a lot of problems. What is nice with import is
> that you have a flat space and you only introduce what you want in one
> place."

I know that "imports" seems like a straight forward way - but please -
read my proposal.
 
> Then there is the question of the renaming.
> 
> 
> Stef

Let me give you a very quick rundown of what my proposal is. I think I
have it distilled in my head to be able to do that. :) First some
terminology for this description (not by any means definite, but I am
leaning towards these names):

"Unqualified name": A reference to a global without a prefix. Just like
today. "Delay" for example. Sometimes referred to as a "short name".

"Qualified name": A reference to a global with a prefix.
"Kernel::Delay".

"Namespace": An object acting like a named dictionary with names and
values. Just like Smalltalk is today. The namespace named "Foo" is
accessible just like a global today.

"LookupContext": An object for the thing I recently have called "Andreas
context". It is an object used by the Compiler and Browsers to do two
things:
	1. Help resolving unqualified names into qualified names.
	2. Help rendering qualified names, possibly rendering them as
unqualified.


Ok, here we go. This is simple:

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