There's is a problem with the naming of classes and their associated namespaces
that must be addressed.
Creating Parrot classes currently requires _typed_ namespaces, that is,
namespaces where more than one object can have the same fully-qualified
name. Parrot's default namespace allows that there be both a namespace and
another object (often a class) with the same name.
Namespace typing is a fine feature for any given HLL to use, but a basic
function of Parrot like class creation must not depend on it.
There's also a more subtle flaw: a violation of the principle of least
repetition. Given a class (let's say it's a Perl 6 class) named foo::bar,
two distinct Parrot entities, both named foo;bar, must be created to
implement it: the class object, and its method namespace. This is weak
design. For example, it makes removing (or renaming) a class into a
multi-step operation.
So here are the changes I'm planning to PDD today:
(1) By default, the implementation objects of a class foo;bar will consist of:
a namespace named foo;bar
a class object named foo;bar;__parrot_class
(2) HLLs will be asked to never use names matching /^__parrot/ for any
purpose.
This edict would apply to HLL maintainers only. (None of us can be held
responsible for the actions of HLL users.) It would also be a more general
rule that we could use to drop other Parrot implementation objects (e.g.
thunks or things we might need to make MMD work) into user-controlled
namespaces.
(3) Parrot default namespaces will be entirely untyped.
That is, in a Parrot default namespace, there will only ever be a maximum of
one object with a given fully qualified name.
==[ Entering alternative universe ]===========================
An alternativeq design has the _classes_ being the visible objects, with
namespaces being externally anonymous and only visible by indirecting
through the classes that use them. This alternative is, of course, entirely
feasible, but it has downsides.
First, some namespaces would become more equal than others: class
namespaces, vs. namespaces unrelated to classes, would require a new
technique for lookup, or else some convention that classes would provide a
namespace interface; neither of these options appeals, especially since the
base namespace interface is 'hash', and I doubt that classes responding to
the hash interface meets anybody's idea of "elegant".
Second (and much less worrisome), users would have to create class objects
before defining any methods for them.
==[ Normality restored ]======================================
==[ Anything you can't handle is now your own problem ]=======
--
Chip Salzenberg <[EMAIL PROTECTED]>
