On 6/28/10 11:42 AM, Andrew Whitworth wrote:
On Mon, Jun 28, 2010 at 2:19 PM, chromatic<[email protected]> 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.
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
