On Mar 15, 2006, at 20:21, Chip Salzenberg wrote:
Neat work, Leo! Couple of comments & requests:
Thanks, yet unfinished though ...
On Wed, Mar 15, 2006 at 08:14:20AM -0800, [EMAIL PROTECTED] wrote:
- initial/default HLL namespace is "parrot"
I didn't ask for a default, and I don't think there should be one, but
I'm
interested in your reason for adding one.
Rationale: the system as a whole *is* Parrot. Looking at Parrot in
context of a running computer system, there is a notional (not
actual)
"parrot::" before *Everything* in a running parrot system. Adding
an
explicit "parrot::" seems to me like adding an explicit "perl::" to
the
beginning of every Perl package name.
The rational for a default "parrot" namespace is simple. Parrot PMC are
bootstrapping themselves by first registering PMC vtables and PMC types
and then methods and MMDs[1]. The methods and MMDs need some kind of
namespace. We were discussing this on IRC a bit. Before all the PMCs
were occupying toplevel namespace names. Now it's "::parrot::Integer"
and so on.
We have already a default HLL named 'parrot' - the initial one in the
absence of any .HLL directive. Therefore it was just straightforward to
use the default ``HLL namespace'' "parrot" as the default one.
I'm of course fine with any other name.
- store_global, find_global w/o namespace are now relative to
current namespace
Excellent.
- intermediate workaround for 'newclass / .namespace': try current
and HLL
namespace to find class namespace
Good workaround, thanks.
Need more specs though. The plan as also described in the roundup mail
is:
.namespace "Foo"
.sub some
cl = newclass "Foo" # namespace "Foo::Foo"
...
or in other words, it's breaking a lot of code. The correct sequence
would need:
# implicit .namespace [""] at top of file, actually all below HLL
namespace
.sub some
cl = newclass "Foo" # namespace "Foo"
.end
.namespace "Foo"
.sub some_other
cl = newclass "Bar" # namespace "Foo::Bar"
.end
Alternatively, we'd need some other means to create nested classes
along with their namespaces.
- getnamespace is absolute to namespace root
I don't think that's a good idea. Once we start making exceptions to
the
relativity rule, users will have to memorize those exceptions, and
then some
opcodes will become less useful. By my intention, the only way to get
to
the namespace root should be via introspection (interpinfo).
Well, I've asked that already and see pdd21:
$P1 = get_namespace ["perl6"; "Foo"]
On the other hand, I think we should consider get_namespace and
find_global
opcodes that accept a namespace PMC as the "root" for the search.
[ ... ]
Whatever might be best. It's not hard to change it now, but we should
have a decision towards final.
BTW could you please add a note to pdd21, how the "add_namespace"
opcode is supposed to work exactly (which namespace name does it create
where)
[1] see the generated file: src/core_pmcs.c:175 and following
leo
