Namespaces TODO list, April 16 '06
Chip Salzenberg
pdd21, here's a list of things that need to be done to bring parrot fully
into the new world of namespaces. The items are roughly in descending order
of importance. There's room for several contributors here....
[[ NAMESPACE PMC ]]
* default namespace needs a typed interface
The good news is that the default {add,del,find}_{sub,var,namespace}()
methods don't have to do much, as the default namespace should be 100%
untyped (i.e. no name mangling should be done whatsoever).
* default namespace needs export_to()
[[ COMPILER PMC AND/OR HLL PMC ]]
* get suggestions for new HLL PMC distinct from compiler PMC, or get
reassurance that compiler PMCs are actually not all that heavy after all
I don't remember who added load_library() to the API of compiler PMCs. I
think that might be a mildly bad idea, since a compiler could conceivably
be a fairly heavyweight object to create. Perhaps an HLL PMC separate
from an HLL compiler PMC could solve this problem.
In the meantime, though, it will work. And we need a hook on which to
hang HLL-specific behavior. Thus the next item, in which we take this
idea and run with it:
* pdd21 wants compiler PMCs to implement load_library() and get_namespace()
I expanded the already documented load_library() with a second parameter
today, and also added get_namespace() to do namespace lookup within the
given HLL's namespace hierarchy.
Both of these methods have reasonable defaults, so it should be possible
for most HLLs to just inherit their
[[ MISC PARROT CORE ]]
* load_library opcode should use <compiler>.load_library()
* get_namespace opcode should use <compiler>.get_namespace()
These are obviously dependent on the previous item. :-)
* introspection and "parrot -t4" should display namespaces as ["a";"b";..]
[[ USER CODE ]]
* standard Parrot libraries not associated with any HLL should have their
own namespaces
For example, PGE should live in a ["pge"] namespace, or, conceivably,
under ["parrot";"PGE"]. In any case, the current double colons are
obsolete.
[[ PDD21 ]]
* pdd21 should document current namespace hierarchy
<leo>
Currently the default compiler's namespace is 'parrot' (for PMCs) and
'__parrot_core' (for builtin MMD subs).
See also $ ./parrot examples/namespace/namespace_dump.pir |less
</leo>
That's the list as I know it. Additions, corrections, and patches welcome.
--
Chip Salzenberg <ch...@pobox.com>
Chromatic
> * standard Parrot libraries not associated with any HLL should have their
> own namespaces
>
> For example, PGE should live in a ["pge"] namespace, or, conceivably,
> under ["parrot";"PGE"]. In any case, the current double colons are
> obsolete.
What should the syntax for creating new objects be? That is, if I define an
object with its methods in the namespace [ 'PAST'; 'Node' ], how do I create
a new instance of that class?
.local pmc node
node = new ???
-- c
Leopold Toetsch
On Apr 17, 2006, at 8:02, chromatic wrote:
> What should the syntax for creating new objects be? That is, if I
> define an
> object with its methods in the namespace [ 'PAST'; 'Node' ], how do I
> create
> a new instance of that class?
>
> .local pmc node
> node = new ???
.namespace ['PAST']
.sub _onload :load
.local pmc node
node = newclass 'Node'
addattribute node, ...
.end
.namespace ['PAST' ; 'Node']
.sub __init :method # and other methods in that namespace
.end
leo
Leopold Toetsch
> What should the syntax for creating new objects be? That is, if I define an
> object with its methods in the namespace [ 'PAST'; 'Node' ], how do I create
> a new instance of that class?
>
> .local pmc node
> node = new ???
Thinking a bit more about it (and discussing this issue with pmichaud)
on #parrot - it seems that we really want hierarchical class names too,
the more that a Perl6 class isa NameSpace too.
That means:
* newclass, subclass, getclass, and new opcodes need variants that take
a Key PMC, e.g.
cl1 = newclass ['PAST'; 'Node']
cl2 = newclass ['POST'; 'Node']
and
obj = new ['PAST'; 'Node']
* the class_hash will be a NameSpace hash instead of a plain 'flat' hash
What do folks think?
> -- c
leo
Chip Salzenberg
[[ NAMESPACE PMC ]]
* The <namespace>.name() method is being renamed to get_name() for
consistency, and to allow for the possibility of set_name().
* The return value of <namespace>.get_name(), the parameter to
<compiler>.get_namespace(), and the parameter to the get_namespace opcode
should all have the same type. PDD21 currently wavers between an array of
strings and a key. Which one will win is still uncertain.
* Namespace object initialization needs to be de-hacked.
Objects of the default namespace type are initialized with a ... creative
use of set_pmc_keyed_str:
void set_pmc_keyed_str(STRING *key, PMC *value) {
...
int val_is_NS = value->vtable->base_type == enum_class_NameSpace;
...
if (val_is_NS) {
PMC_pmc_val(value) = SELF; /* set parent */
PMC_data(value) = key; /* and name */
...
}
}
If I'm reading this correctly, the way a namespace object named ["a";"b"]
is initialized after creation is by
$P0["a";"b"] = parent_namespace_pmc
Which is creative but really far too hacky to live, because it means that
the untyped interface is broken (badly!) for namespace values (not to
mention that it doesn't notice correctly when its parent namespace is of
a *customized* namespace type).
So another way to initialize namespace pmcs must be found pronto. I'm
pondering it.
--
Chip Salzenberg <ch...@pobox.com>
Chip Salzenberg
> Thinking a bit more about it (and discussing this issue with pmichaud)
> on #parrot - it seems that we really want hierarchical class names too,
> the more that a Perl6 class isa NameSpace too.
>
> That means:
>
> * newclass, subclass, getclass, and new opcodes need variants that take
> a Key PMC, e.g.
>
> cl1 = newclass ['PAST'; 'Node']
> cl2 = newclass ['POST'; 'Node']
>
> and
>
> obj = new ['PAST'; 'Node']
"I am intrigued by your ideas. I wish to subscribe to your newsletter."
PS: that means I like it
--
Chip Salzenberg <ch...@pobox.com>