A little namespace "proposal"

goran.krampe at bluefish.se goran.krampe at bluefish.se
Mon Apr 19 11:26:26 UTC 2004


Hi Lex!

"Lex Spoon" <lex at cc.gatech.edu> wrote:
> 
> Ah.  I see, Goran, that I misunderstood the baseline proposal.  The last
> sentense of this clause is important:
> 
> > 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.
> 
> Also, you give this code example:
> 
> 	Object subclass: #NameOfSubclass
> 		instanceVariableNames: ''
> 		classVariableNames: ''
> 		poolDictionaries: ''
> 		category: 'Kernel-Processes'
> 		namespace: 'Kernel'

Yes, both this shows that you specify the namespace that a class *lives*
in just like you specify which category it "lives" in. Same thing. (even
though I now use the name instead of an extra keyword)

> I must admit that I still do not understand the proposal entirely.  I
> guess I can wait until your implementation is shaped up.

I will shortly post a version in which you can convert the Basic image
into a bunch of namespaces to see how it feels. I have it working in my
dev image, just need to tweak it a bit.
 
> As one small comment, if the only purpose of namespaces is to provide
> short names, then it seems like namespaces should be maps of names to
> names, not of names to bindings.  So they should be different from our
> venerable Smalltalk dictionary.  But maybe I misunderstand the point.

It is not the *only* purpose. Another purpose is of course the avoidance
of naming conflicts - or rather - the "graceful handling" of them. And
yet another purpose is about the ability to do shadowing - even though
it is mostly a dubious practice in my opinion. And another purpose is to
be able to do more advanced namespace level refactorings, like for
example - "remap all references to Tweak::* to Tweak2::" etc. 

But IMHO *name*spaces are about names and bindings. And as little as
possible about other things. :)

> One thing that bothers me is the idea that a class will only be
> interested in a single namespace.  If I write some code, it seems that I

No, you are misinterpreting the class creation template as if it was an
"import". It is not.
The class *resides* in a single namespace. It has no imports so it has
no notion of "interest".

> may very well want to import from both Tweak and from
> RegularExpressions.  Why should I have to pick which short names my code
> will be allowed to use?

You aren't picking, see above. :)

> Also, I still do not see exactly how Alice will get short Tweak names in
> the example scenario I posted.  While she will have Andreas's class
> definition that says namespace: 'Tweak', how does she receive a useful
> Tweak namespace to begin with?  That is the issue I am worried about. 
> The namespaces need to travel along with the code that uses them.

I think this all is some great misunderstanding of my proposal or
something.
I just hope my code can show it more clearly. And it does have some
class comments too. :)

> Ah well.  Overall, I am glad to see that people are considering end user
> aspects so thouroghly in this discussion, even if I am confused about
> the specifics that are being bantered about.
> 
> Lex

Yes, IMHO this is almost *exclusively* about end user aspects. Names in
themselves are for *us* not the Compiler. This is also why I can't see
"just use some UUIDs" to solving it.

Anyway, I will see if I can post my latest later today.

regards, Göran



More information about the Squeak-dev mailing list