A little namespace "proposal"

Roel Wuyts Roel.Wuyts at ulb.ac.be
Tue Apr 6 12:29:49 UTC 2004


One simple question I had when reading the proposal (and before really 
giving comments):

What exact problem do you want your namespaces to solve (I am not 
talking about the primary values of your solution)?
Is it name clashes?

(several people here want to solve different things with the 
"namespaces" - from simple naming conflicts to different scope lookup 
mechanisms to more packaging-issues to deployment to .... So I'd like 
to be sure :-) )

On 06 Apr 2004, at 11:53, goran.krampe at bluefish.se wrote:

> Hi all!
>
> On the bus home I was sitting trying to figure out how *I* would like a
> namespace enabled Squeak to work. This post will try to describe it and
> I assume Andreas, Avi, Stephane and other more accomplished Squeakers
> than I will shoot it down in flames. :)
>
> Primary values I have sought to fulfill:
>
> - Simplicity (for example, there are no "imports")
> - Making it work "optimistically"
> - Somewhat backwards compatible in the meaning that most things will
> "work just like now".
>
>
> It goes something like this:
>
> - Instead of having one big bag of globals (Smalltalk) we have a a
> number of Namespaces. A Namespace is just a Dictionary of associatons
> between names and objects like Smalltalk, and the Namespaces aren't
> related to each other in any way - we just have a flat list of them. So
> typically we have say these Namespaces (which I will use in the rest of
> the post as examples) and many more:
>
> 	Kernel
> 	Collections
> 	SqueakMap
> 	Seaside
>
> (note how I have made this a bit coarser than the categories - of 
> course
> the actual partitioning is open for discussion, but just bear with me
> for this post)
>
> - When creating a class in a class category the template would look
> like:
>
> 	Object subclass: #NameOfSubclass
> 		instanceVariableNames: ''
> 		classVariableNames: ''
> 		poolDictionaries: ''
> 		category: 'Kernel-Processes'
> 		namespace: 'Kernel'
>
> ...thus autopicking the PI-first part of the category, or perhaps like
> this:
>
> 	Object subclass: #Kernel::NameOfSubclass
> 		instanceVariableNames: ''
> 		classVariableNames: ''
> 		poolDictionaries: ''
> 		category: 'Kernel-Processes'
>
> ...whichever we like the best.
>
> - There is no explicit "creation step" for a namespace (or removal) -
> they are simply created and removed "on demand" or whatever. This means
> we all can "carry on just like before". :) Or in other words, it is an
> attribute of the class.
>
> - When writing code you can refer to the class Delay in two ways -
> "Delay" or "Kernel::Delay":
>
> 1. If you type in "Delay" then we first look in the local Namespace of
> the class you are editing. If there is a "Delay" in that namespace then
> we bind to that. If not, then we look in ALL other Namespaces and if it
> resolves in none we signal an Exception. If it resolves to one we ask
> the user to confirm the right binding. The source will still read
> "Delay" but the binding is still in itself fully qualified as
> "Kernel::Delay" since it is in fact an object reference to that class.
> If it resolves to more than one, the user gets to choose which one and
> it will be expanded to "Kernel::Delay" in the source (if that is the 
> one
> he/she chooses).
>
> Note to Andreas: The signals and code here is of course up for
> discussion, I really don't care as long as the end result is the same.
> :)
>
> 2. If you type in an explicit reference "Kernel::Delay" then the
> Compiler (or whatever) first checks for the Namespace "Kernel" and if
> that exists looks for the name "Delay" in it. If it isn't resolved then
> an Exception is signaled and the Browser should look through all other
> Namespaces for "Delay" and if found - ask if it should be corrected. If
> there is only one Delay in the system to find, then it can be corrected
> to "Delay", otherwise it will be corrected to the fully qualified form.
>
> The net effect of the above is that Squeak code as it stands today 
> still
> works fine after a recompile. I think. :). Note also how this 
> eliminates
> the needs for imports, the short form is usable in two scenarios:
> 	1. The name referenced is in the local namespace.
> 	2. There is only one such name in all the other Namespaces.
>
> This will also encourage us to to still have globally unique names in
> our packages which is a GOOD thing because no matter how cool 
> namespaces
> we have - it all ends up in our heads - and our heads is just one big
> namespace. If many namespaces have "Delay" entries, it will still mess
> with our heads. See below for a little "feature" that still makes it
> possible to have duplicate names without "disturbing others".
>
>
> - When a new class "SqueakMap::Delay" is created the tools should warn
> me that there already is a class called that in another Namespace and
> that it is generally better if the classes don't conflict by name
> because of the way resolving works. Sure, currently (before we get a
> superserver somewhere that can do lookups globally) this only checks
> against my current image but should still be useful.
>
> I then have a choice:
> 	1. Keep the name Delay and thus causing people with my code and the
> Kernel code in their image to be forced to choose which Delay they mean
> every time they only write "Delay" instead of a fully qualified name.
> 	2. Rename it to MapUpdateDelay and be fine, that might very well be a
> more precise name.
> 	3. Keep the name Delay but mark the name in the namespace as "shy". 
> All
> names in all namespaces are by default used when trying to resolve a
> non-qualified name (as the resolving algorithm above showed - this is 
> at
> the heart of the "optimism") and marking it as "shy" merely means that
> when someone writes "Delay" the entry "SqueakMap::Delay" will not be
> presented as a choice. It doesn't mean anything else - for example,
> typing "SqueakMap::Delay" works just fine regardless if it is "shy" or
> not.
>
>
> - The Dan-test, what happens when we install/uninstall a package of
> code? Well, I am completely disregarding stuff that Monticello already
> solves/tries to solve. So let us only look at what we do with our
> Namespaces.
>
> Since the fact of which namespace a class resides in is an attribute of
> the class itself it means that new code filed in can:
> 	1. Introduce new Namespaces
> 	2. Add entries to existing Namespaces
> 	3. Overwrite entries already in existing Namespaces
>
> If we only would allow the first 2 then all would be trivially simple.
> :) Since all existing references in the image (see above) are fully
> qualified then new entries or namespaces can't affect anything.
>
> What happens with the overwrites? Well - I am not sure - Avi can 
> perhaps
> help out in this area. One idea is to add a mapping mechanism to the
> filein code. Trying to file in an overwrite will simply signal an
> Exception and the user will have to add a mapping perhaps just putting
> it in another Namespace to at least get the stuff in.
>
>
>
> Ok, enough for now, cutting this short so that Avi get a chance to read
> until he falls asleep. What do you all think?
>
> regards, Göran
>
>
Roel Wuyts                                                              
   DeComp
roel.wuyts at ulb.ac.be                               Université Libre de 
Bruxelles
http://homepages.ulb.ac.be/~rowuyts/                                    
Belgique
Board Member of the European Smalltalk User Group: www.esug.org




More information about the Squeak-dev mailing list