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. 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
