How to inject methods

Allison Randal allison at
Mon Jun 28 21:31:12 UTC 2010

On 6/28/10 11:42 AM, Andrew Whitworth wrote:
> On Mon, Jun 28, 2010 at 2:19 PM, chromatic<chromatic at>  wrote:
>> 1) You have a NameSpace PMC.  You look up a symbol in that PMC.  You get back
>> something you can invoke: something that isa or does Sub.  Is it a method?
> I think you're misunderstanding my question. The NameSpace PMC
> contains several sets of things: It contains a set of globals, a set
> of methods, etc. We can access the set of globals from PIR, we cannot
> really access the set of methods from there. Even if it was a
> read-only set (after PBC load time, of course), we should still have
> access because the data is still there and there are legitimate uses
> for it.
> But beyond that, there's a fundamental difference between what a Class
> does, and what a NameSpace does. I don't think anybody here thinks, or
> wants to think, that Objects are related to the NameSpace in the same
> way that they are related to Classes. The NameSpace really has more of
> a relationship with PBC than anything, and the list of "methods" in
> the NameSpace generally represents the methods that have been
> explicitly defined in PBC as being part of that namespace.

Dangerous fallacy alert here, which I'll explicitly correct since there 
was some early abuse of the feature: A NameSpace does *not* have a 
relationship with the PBC, it is not a dumping ground for everything 
IMCC doesn't know how to handle.

The "namespace" is a compiler feature, a hierarchical tree that stores 
the *global* symbols of the language, both variables and subroutines. 
That hierarchy is important, as it (somewhat) ameliorates the overall 
problems of global variables, by partitioning the one massive global 
storage space into smaller named global storage spaces, providing some 
protection from collisions. But they're still global symbols. We 
happened to choose to implement the namespace tree as a hash-of-hashes, 
where each "hash" is a PMC object called NameSpace, but this is purely 
an implementation artifact. It could just as well be any tree-like data 
structure (and may in the future be some other data structure, for 
optimization reasons).

The reason methods were stored in the namespace originally was because 
Dan didn't understand object oriented code (a fact that he freely and 
happily admitted, regularly). We shouldn't take historical precedent as 
the definition of good architecture.


More information about the parrot-dev mailing list