At 10:13 AM -0800 1/13/04, Jeff Clites wrote:Short version: I was originally going to argue for fully hierarchical namespaces, identified as above, but after turning this over in my head for a while, I came to the conclusion that namespaces are not conceptually hierarchical (especially as used in languages such as Perl5 and Java, at least), so I'm going to argue for a single string (rather than an array) as a namespace identifier.
It is probably worth pointing out that even in Perl5 namespaces are implemented as though they were hierarchical. They're passed around as strings ("Foo::Bar::baz"), but when a variable is fetched (C<Perl_gv_fetchpv()> in gv.c), perl parses the string as though it was a multidimensional key, with dimensions separated by "::" "'". As Uri pointed out, this makes it easy to take and pass around references to stashes; it also reduces memory usage, since there is only one copy each of "Foo" and "Bar", regardless of how many items are in %Foo::Bar:: .
Performance-wise, I would guesstimate that it's more-or-less a wash between parsing strings and parsing multidimensional keys, so as long as we precreate the keys (keep thm in a constant table or something), I see no performance issues.
Just keep the variable's name separate from its namespace (as codified in pdd06), and IMHO we should be golden with multidimensional keys.
Here's my big, and in fact *only*, reason to go hierarchical:
We don't need to mess around with separator character substitution.
Other than that I don't much care and, as you've pointed out, most of the languages don't really do a hierarchical structure as such. Going hierarchical, though, means we don't have to do "::"/":"/"/"/whatever substitutions to present a unified view of the global namespaces.
But we do need to worry about cross-language namespace collisions... :-D
-- BKS
