On Tue, Mar 07, 2006 at 05:21:43PM +0100, Leopold Toetsch wrote:
> Chip Salzenberg wrote:
>
> >Thanks for the good questions, I hope this answers them.
>
> Thanks, yes. So I got a new one ;)
No rest for the wicked. :-)
> In which namespaces should Parrot store PMC methods and multi subs?
> Currently Parrot occupies these namespaces:
>
> __parrot_core ... buitin multisubs like '__add'
> Integer ... all PMCs with methods are in a toplevel namespaces,
> String with their class name
> ...
Working from first principles, and making some progress, I write (and invite
analysis of) these points:
1. The default target for 'newclass' must be inside the current HLL, or else
Parrot and Perl code can't both say 'newclass "Integer"'.
Confidence: HIGH
a. This implies that there should be a variant of newclass for global
classes. A 'newglobalclass' opcode is the most obvious solution, and
simultaneously the least elegant, because it implies that there will
be other *global* opcodes, and I don't like where that's going.
Alternatively, newclass could accept an optional starting namespace
parameter, which defaults to the current HLL namespace.
Confidence: HIGH in need for solution, LOW in actual solution
2. Therefore, class lookup must be two-level: the current HLL first, and the
global list.
Confidence: HIGH
a. Does this imply that we should allow users to see and modify a list
of namespaces to search for classes, a la $ENV{PATH}?
Confidence: LOW, but intriguing
3. Under the assumption that PMC names are supposed to map to HLL class
names (else what will?), it makes a lot of sense for newclass, the new
operator, etc. all to allow multi-level names.
Confidence: MEDIUM; it's possible that explicit namespace manipulation
could take the place of full keyed names here, and perhaps
also help solve the problem described in 1(a) above.
4. I'd like for global Parrot classes to live in a namespace other than the
root, and that name should be something users can count on so they can
do introspection (e.g. to detect name conflicts).
Let's call it "class".
Confidence: HIGH (cluttered roots are bad)
a. Just like the HLL namespace, it makes sense to cache this namespace
pointer, so we don't have to keep looking it up.
And a bonus policy point:
5. All root names (including root namespaces) that start with '_' shall be
designated now and forevermore to be something that users are not allowed
to count on (though of course exploration is always allowed).
So it's OK for us to leave the builtins in '__parrot_core', because I
don't have any better suggestion at the moment, and we can move them
later. Any users who depended on finding them there will have broken the
basic rule I just made up.
(Besides, the leading '_' should clue in anybody who's ever used C or
C++ that it's private, which is presumably what was intended anyway.)
--
Chip Salzenberg <[EMAIL PROTECTED]>
