On Thu, May 18, 2006 at 03:17:36PM -0700, Chip Salzenberg wrote:
: What's the relationship in perl6 between namespaces and classes?
Hmm, well, that's hard to put one's finger on, but to the first
approximation namespaces are for declarational names, while classes
can really only name things operationally. So packages, modules,
classes, roles, subsets, enums, etc. all pretend they are packages
for purposes of naming from a global root. Any extra semantics are
defined by the objects that support each type of declarator. But
as container objects they all support the Package role, or some such.
The situation is analogous to the filesystem. We have a /proc
filesystem nowadays because it's convenient to name certain
abstractions in the OS as if they were ordinary files despite most
of the actual magic being defined elsewhere. It would be possible
to access classes et al. only via the mechanisms supplied by the
metaobject protocols, but that would be kind of like the bad old
days when ps(1) had to rummage around in /dev/kmem to figure out what
to say.
: For example, given:
:
: package Foo { sub bar {...} }
: class Corge { method grault {...} }
:
: Is the full name of foo "&Foo::foo"?
Yes, assuming that Foo is a top-level package name, and that you meant "bar".
: What's the full name of grault?
Just as if the class were a package:
&Corge::grault
Though nowadays for clarity we often write these as
Foo::<&bar>
Corge::<&grault>
instead.
: Is there a common role that Foo and Corge both do?
As bare names they can be taken in context to mean either the package
or the type. When necessary we can disambiguate these:
Foo.^{$x} call .{$x} on the type metaobject
Foo::{$x} call .{$x} on the package object
Contextually, though, a bare package name is generally taken to be a pun on
the type unless followed by ::. So
my Corge $foo;
is not really saying much about the Corge package except that there has
to be one, and to the extent that the Corge type supports certain methods
at declaration time, those names appear to be in the Corge package.
It's quite possible that the Corge type has metamethods that let us
get at unnameable behavior, but that would generally be construed as
violating encapsulation--hopefully for a good reason--but the public
interface of a type should generally be presented declarationally
via packages and the objects they contain.
A consequence of all this is that when you use any type declarator:
module M ...
class C ...
role R ...
subset S ...
enum E ...
the name is referring to both the package and the type simultaneously,
and the type is allowed to present whatever public interface it likes,
generally via the package. It also presents an internal declarational
interface to the innards of the declarator, so that metamethods like
"has" and "does" and "is" are given meaning in your class declaration.
The type also presumably controls which traits make sense on various
declarations.
Interestingly, even the tag groups of module exports are done with
the package interface currently. The "is export (:DEFAULT)" trait
merely pokes the current name down into the ::DEFAULT subpackage of
the module, and it hopefully can become very efficient to import a
prepackaged set of symbols as a lump.
If this isn't answering what you were asking, please ask s'more,
and I'll try to reply when I'm not busy having a grandbaby.
Larry
