Thank goran for your summary

I have a question:
 From one method in Foo::Bar, I can refer to ZZ::X. I guess that this is 
possible
and this is what I do not like. I'm curious to see the future.
You use flat not in the same way I do (for me flat means that from 
within the methods you cannot see outside a namespace because there is 
no namespace conceptually).

I do not really understand why having an import statement that would be 
feed in by the LookupContext would not be a better solution. This way 
you cannot have spaghetti reference at the method level.

I tried to contact you on IRC but now this is too late for me. I have 
to leave.
Stef


On 8 avr. 04, at 12:22, goran.krampe at bluefish.se wrote:

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