On Sep 13, 2004, at 1:07 AM, Luke Palmer wrote:
Jeff Clites writes: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.
Does:
print ${$Foo::{"Bar::"}{baz}}
Count as explicit introspection?
Well, that's another one of those cases where I don't see that it gives the programmer power that you don't already get by being able to do: print ${${"Foo::Bar::"}{baz}}.
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
A debugger.
I'm not sure exactly what you mean--if you're referring to being able to have a debugger intercept name resolution for only certain namespaces, then all you need to get this is the ability to intercept all name resolution--and just fall back to the default for namespaces you don't care about.
If you're talking about the ability to have the debugger dump out all namespaces with "Foo" at the top, or do a hierarchical printout, then a debugger can certainly do this without having truly nested namespaces. That's just output formatting/logic, really. And of course, that's introspection.
Sure. That's not the idea behind the heirarchical namespaces either. A
lot of power comes out of being able to treat namespaces as a tree-like
data structure (I can actually attest to this: see Class::Closure), as
was pointed out before, being able to treat namespaces as a filesystem.
For me, the filesystem metaphor plays out a little differently. I think of an individual namespace as being like a DB file. It's convenient to organize files via a hierarchical filesystem--but files are not themselves nested (you don't have files inside of other files), and the API of files (open/close/read/write/seek/truncate) has nothing to do with anything hierarchical. So for me the analogy means that it's convenient to have hierarchical organization so that humans can keep CPAN organized, but that doesn't have runtime consequences.
Also, Perl 6's classes will behave more heirarchically:
module Foo;
class Bar {...} my $x = Bar.new; # Actually works, while Bar is Foo::Bar.
But Java has something similar (inner classes), and does it without nested namespaces. In fact it (I believe) unwinds stuff like this completely at compile-time, so that your last line compiles down to the same thing as "my $x = Foo::Bar.new;".
What might do it for me, would be if stuff like this worked:
module Foo;
$x = 7; class Bar {...}# now, in a different lexical scope...
sub Foo::Bar::blah { ++$x; } # Resolves to $Foo::x, because "Bar is inside Foo"
# now, elsewhere at runtime
...some syntax which moves Bar from module Foo into module Zoo at runtime
then the above sub is Zoo::Bar:blah, and $x resolves to $Zoo::x, if that exists
Not that I think any of that would necessarily be a good thing to have, but it would be the sort of thing which would naturally be implemented via nested namespaces. (And, if any significant language allows this sort of run-time namespace hierarchy rearrangement, then I'd see that as a good reason to nest--so that we don't cut out a whole language from Parrot-targetablility.)
But, that said, I think I'm pretty much the only person who thinks that namespaces shouldn't nest conceptually. And I'm really more worried about the other issue I brought up, about how do deal with interoperability between different languages which have different ideas about namespace segmenting between different types of entities. That's a bigger "problem".
JEff
