How to inject methods

[Andrew Whitworth]

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. What I want
is an ability to access (if not modify) the set of methods in the
NameSpace. I do not want, nor do I think we would expect, the
NameSpace to contain a faithful list of all methods in the Class, or
available to Objects of that Class through inheritance and mixins.

> 2) You have a NameSpace PMC connected to a class.  You add a Sub to that PMC.
> The name you use happens to collide with the name of a method in a parent
> class.  Which Sub PMC should you call for method dispatch?

The namespace is where methods get defined. Then they are moved to the
Class where they are included in a lookup hierarchy. If I ask a
question "What methods are defined in this namespace?", I would expect
the answer to be different from "What methods are available to an
object of this class?". At the very least, the first question should
get an answer.

A lot of semantics would need to be fixed or redesigned if we wanted
the ability to store a method Sub in the namespace as a data item like
any other PMC can be stored there. I think we will want that ability
eventually, so that we have clear and consistent namespace storage
semantics. We certainly don't support it now.

> 3) You want a list of all methods in a NameSpace.  How do you avoid false
> positives and false negatives?

No, only the methods that were defined in that namespace. Possibly
even restricting to "Subs that the programmer explicitly wrote under
the .namespace[] directive in a code file". I don't propose that
namespaces be subjected to inheritance like Classes are, and I don't
propose that the namespace's list of methods should necessarily
reflect the list in the Class if methods are injected into the class
at runtime (or vice-versa). Classes and NameSpaces are different, I
want to use each in different ways and not try to force one to fill in
for behaviors that the other is missing.

--Andrew Whitworth