How to inject methods
allison at parrot.org
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 wgz.org> 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
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