On Sep 27, 2004, at 8:55 AM, Dan Sugalski wrote:
Okay, I've come to realize that it really helps if I'm clear about what I want, which kinda requires being clear about what I want.
There are two things in the namespaces I'm concerned about.
First are the actual objects one grabs out. Variables, sub objects, class objects -- actual "stuff". Languages seem to fall into two categories -- those that group subroutines in with data and those that don't. (Most generally do)
Second there's the structure of the namespace. I really do want Foo::Bar to be handled with a Foo entry in the top-level namespace, and a Bar entry in the Foo namespace, and nothing that anyone does to any Foo "object" at the top level can damage that.
What I proposed in my 9/26/2004 post to the "Namespaces, part 1 (new bits)" thread directly accommodates all that.
Here is how that looks in data structure terms. (I'll use hash notation here, though the actual implementation could optimize.)
Let's say that all you have around are $Foo and $Foo::Bar::baz -- that is, a Foo variable at the top level, and a bar variable inside a Bar namespace inside a Foo namespace. The namespaces involved could look like this:
top-level namespace (say this is namespace #1):
{
variables => { Foo => <PerlScalar PMC (or whatever)> },
namespaces => { Foo => <PerlNamespace PMC, call namespace #2> }
}namespace #2 (the namespace from above):
{
namespaces => { Bar => <PerlNamespace PMC, call namespace #3> }
}namespace #3 (the namespace from immediately above):
{
variables => { baz => <PerlScalar PMC> }
}It doesn't matter if the sigils are treated as part of the name--the structure's the same, you just have "$Foo" and "Foo::" up there instead. (Though Perl maybe could have done without the structure for variable v. namespace, other languages don't have a natural syntax to distinguish them.) And of course, you'd have a "subs => ..." section if we had any subs in our example.
My above-mentioned post explained what you'd do for Python, and how it fits well into this. And for languages which need more sections, they would be accommodated as well.
The fact that the Foo class has an object named Foo at the top level which you can fool with is separate from the fact that there's a Foo *namespace* at the top level. Using a filesystem analogy, I want to have a directory and file named Foo, with file operations not touching the directory, and directory operations not touching the file.
Yep, that does that.
It seems like the simplest thing to do is to have a *real* unified system and go with a prefix or suffix scheme for namespaces that the namespace ops automatically pre/post-pend on the names.
I don't think there's any need for name mangling--that's the sort of thing you do when you need to shoehorn extra information into a structure that wasn't designed to hold it.
If you want to name mangle, _and_ not arbitrarily restrict what characters a language might allow in identifiers, then it makes sense to give everything a prefix, and it's unambiguous that the prefix is everything up to your first separator character (say, slash); for example: "namespace/Foo", "variable/Foo"--there's no ambiguity or restriction, for instance "variable/foo/bar" is just the "foo/bar" variable in some language which allows slashes inside of variable names. And just to close the loop, you'd still express your $Foo::Bar::baz lookup like:
lookupVariableInNamespace P1, ["Foo"; "Bar"], "baz" # the things in the [...] are always namespace names
Logically, that's identical to what I have above--it's just another way to express the same structure, just an internal implementation detail, with some pros (maybe one less hash lookup) and cons (more intermediate strings created). You'd still say a given namespace has different "sections" to accommodate different categories of entities.
JEff
