A little namespace "proposal"

goran.krampe at bluefish.se goran.krampe at bluefish.se
Wed Apr 14 23:23:20 UTC 2004


Hi all!

I just HAVE to reply, especially now that Dan joins the fray. :)

Dan Ingalls <Dan at SqueakLand.org> wrote:
> >I like the email of lex. Now I do not really understand why there is something wrong with the following code
> >
> >I prefer to show code that write names since we all have a different understanding of them ;)
> >
> >Tweak namespace new
> >	import: MorphWithExtraLongName from: Morphic
> >	import: Scheduler from: Kernel;
> >	import: lkjlkjl from: Grrrrr;
> >
> >MorphiWithExtraLongName subclass: #MyWonderderfullClass
> >	...
> >
> >MyWonderfullClass>>myWonderfulMethod
> >	....
> >	Scheduler start
> 
> 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'

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



More information about the Squeak-dev mailing list