On Sep 12, 2004, at 8:43 PM, Luke Palmer wrote:
Jeff Clites writes:On Sep 7, 2004, at 6:26 AM, Dan Sugalski wrote:
*) Namespaces are hierarchical
So we can have ["foo"; "bar"; "baz"] for a namespace. Woo hoo and all that. It'd map to the equivalent perl namespace of foo::bar::baz.
How does this hierarchical nature manifest? I ask because I don't know of any languages which actually have nested namespaces,
Other than, um, well, Perl.
As an implementation detail yes, but I can't think of any Perl code (except for explicit introspection) which "reveals" this. That is, seemingly nothing about Foo::Bar comes out of Foo, nor is it necessarily related to Foo::Baz.
so I'm not sure what this is meant to imply. In particular, if this implies cascading lookup (meaning that a symbol looked up in ["foo"; "bar"; "baz"] would fall back to looking in ["foo"; "bar"] if it didn't find it), than that's not how Perl5 packages work.
No, the lookup is not cascading downwards. It is cascading upwards, however, so that in:
[ "foo"; "bar"; "baz" ]
The [ "foo"; "bar" ] part can be implemented differently. This means that Python's namespaces and Perl's namespaces can have different semantics. Picture a PythonStash and PerlStash pmc.
Sure, if they're nested then the "baz" namespace is looked up inside of "bar" which is looked up inside of "foo"--I get that. But what I'm wondering is, let's say you have $Foo::Bar::someVariable (in Perl5 syntax). That means "look up $someVariable, inside of the Foo::Bar namespace". Now, let's contrast two ways this namespace name might compile down:
["Foo"; "Bar"]
v.
["Foo::Bar"]
Now, what would behave differently in those two cases, in terms of the behavior of $Foo::Bar::someVariable? I can't think of anything.
Now it's true that if you think it's really important to tie namespaces such that you can take over the name resolution for ["Foo"], then you'd want the former. But I don't see that as really terribly useful--in the examples I've heard of (e.g., turning the namespace lookup into an Oracle fetch) have seemed to not provide much that a tied hash doesn't. And there are currently a ton of, for instance, Text::Blah modules on CPAN--but that doesn't actually mean that they have anything to do with a "Text" namespace--that's not the intention, and most of these modules have nothing to do with each other. That naming is to keep them conceptually organized, not functionally.
I can certainly see having different namespace semantics for different languages, but that doesn't imply arbitrary nesting. That might imply separate "top-level" namespaces, each with its own behavior (so overall, two levels of namespace), or you could just have one-level namespaces, but each with its individualized semantics, or all namespace might be represented by the same type of data structure, which is just traversed differently from different languages. (And I'm not sure that the semantics do differ between languages--given a namespace and a name, there's seemingly only one thing to do.)
And again, I don't so much object to the idea of nested namespaces--I just feel that they'll slow down symbol lookups, without giving us much in return. I'm afraid we're adding complexity we don't need.
JEff
