Chip, we briefly discussed this on IRC yesterday, but I wanted to
make sure this didn't get lost.
I don't like the impact that this is going to have on HLL languages -
it's exposing internal bits of parrot to the HLL programmers. The
argument that we already expose some bits (for example, certain
method names are restricted for classes), does not, in my mind, mean
it's OK to add more. We should be removing the bits that already are
exposed. (see also ancient python discussions.)
My concern is that, in an effort to work around this restriction,
each language will end up implementing a workaround to hide the
__parrot* namespaces: these workarounds will hinder interoperability
unless they are synchronized: if they're synchronized, why not
canonicalize them and put it in the core?
That said, I'm still trying to figure out why a class's methods have
to be stored in a namespace: I don't see any reference to this in the
object or namespace PDDs, except for a single line in PDD15:
Classes have an associated namespace. (Which may be anonymous)
Can you provide some insight here? Matt Diephouse suggests that it's
because methods are subs, and subs live in a namespace - but is there
a use case (HLL requirement) for doing _namespace_ lookup for finding
a method in a class? That is, is anyone ever going to call methods
by looking them up in a namespace PMC and invoking them, as opposed to:
$P1.'method'()
or
$P2 = find_method $P1, 'method'
$P2()
In both cases here, we're going off the vtable for that particular PMC.
Regards.
On May 16, 2006, at 1:32 PM, Chip Salzenberg wrote:
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]>
