hi
>> Hi, Stef -
>>
>> Thanks for the concrete example.
>>
>> Does the first line declare the following imports as part of a 
>> namespace named 'Tweak', or are we creating an as-yet-unnamed 
>> namespace  by sending a message to a global object Tweak (like 
>> Smalltalk)?  If the former, the I was expecting something easier to 
>> execute (ie receiver doesn't start out undefined) like
>> 	Namespace new named: 'Tweak'
>
> In my code (which actually works pretty much 95% right now, including
> the tools) I can do this to explicitly create a Namespace:
>
> 	Namespace newNamed: #Tweak
>
> Which will create a new Namespace instance with a name instvar holding
> #Tweak and it will also put that instance in Smalltalk. But I would
> typically not do that, instead I would just do this (yes, works fine):
>
> Object subclass: #Apple
> 	instanceVariableNames: ''
> 	classVariableNames: ''
> 	poolDictionaries: ''
> 	category: 'Tweak'
> 	namespace: 'Tweak'

I don't like the namespace import at the class level. We will have to 
type that all the time.
Imagine a similar symbol can point to different stuff depending on the 
class.
We have that in VW and this is bad. I discussed long time ago on the VW 
mailing-list
but I do not have the time to dig and find the argument.

>
> This is the default template in my image when clicking on a category.
> The class Apple will be hooked into the Tweak:: (and NOT in Smalltalk)
> namespace and the Namespace instance will be created if it doesn't 
> exist
> at this point. So if you don't care - then your namespaces will be
> 1-to-1 with your categories (up to the first dash).
>
> Then these expressions evaluates to true demonstrating 4 different ways
> to refer to the class:
>
> 	(Smalltalk at: #Fruits::Apple) == ((Smalltalk at: #Fruits) at: #Apple)
>
> The left hand shows that SystemDictionary has some "compatibility
> behaviour" making it seem as if the qualified names are all accessible
> "flat" in Smalltalk, which they aren't. It will do a two step lookup
> like the right hand shows.
>
> 	((Smalltalk at: #Fruits) at: #Apple) == Fruits::Apple
>
> Here the right hand shows that Scanner/Parser has been augmented to
> properly handle qualified names (with a little help from Andreas).
>
> 	Fruits::Apple == Apple
>
> And finally we see that since Apple in this case is the only class in
> the image with that name (there is no Tweak::Apple) the unqualified 
> form
> works as well. The modified Parser>>correctVariable:interval: method
> will autocorrect it to the fully qualified name by asking LookupContext
> (I just have a class as singleton right now to keep this logic visibly
> pluggable). Yes, the above expressions evaluates just fine in my 
> current
> dev 3.7-5868 image.
>
> In my proposal I don't allow Namespaces to form a hierarchy, instead
> they are all kept "sisterly" in Smalltalk. A part from that they are
> much like Environment is - I even reused the instvar in Class :) so
> that:
>
> 	Fruits::Apple environment == Fruits
>
> ...meaning that Namespace is a subclass of IdentityDictionary with
> regular keys and values just like Smalltalk is today.
>
>> If I were writing myWonderfulMethod and accepting it for the first 
>> time, would the programmer's assistant offer up a menu like...
>>
>> "Scheduler is not defined in this namespace..."
>> 	|  import from Kernel
>> 	|  import from NewSchedTest
>> 	|  ----------------------
>> 	|  declare local
>> 	|  declare global
>> 	|  leave undeclared
>>
>> If so it would be fairly consistent with what we have now.
>
> My proposal asks too - but it doesn't add any import list or anything,
> it just expands the name to be fully qualified.
>
> But this is where the magic trick comes in, and since Dan may have
> missed my proposal I repeat it, all references are stored in the source
> as *fully qualified* but are *rendered* in the browser method panes in
> the unqualified form if either the name is defined in the local
> namespace (the namespace of the class) or if there is just one name in
> the whole image. I actually found some neat code from you Dan that I
> rewrote to do these renderings using globalSourceRanges etc in
> MethodNode. So it works perfect even for alternate syntaxes, pretty
> printing etc.
>
>> 	- Dan
>
> I will post what I have in a few hours - it is still buggy, but you can
> at least see that it does indeed work and that there is no need for
> imports IMHO.
>
> regards, Göran
>