On 6/28/10 10:52 AM, Andrew Whitworth wrote:
I'm running into a problem in Kakapo caused by the TT #389 changes. Kakapo defines a number of extension methods for built-in PMC types and injects those methods into the respective classes/pmcproxies. However, this mechanism is significantly harder after the TT #389 fixes and in some cases I haven't found any way to do the things that I need.
Could you give us a little more detail on what the problem is? Methods should be looked up in the Class, and we provide that introspection mechanism. Subs are looked up in the NameSpace and we provide that introspection mechanism. And, the class object is stored in the namespace, so you can always find the method object even if all you know is "I'm looking for method X associated with class Y." It's still easily possible to add methods at runtime. The only change is that when you add a method (at IMCC compile time or runtime) it is only stored in the class, instead of mixed in with the subs and variables associated with that namespace.
If the perspective helps you any, NameSpaces are like a kind of retarded class that invokes without an instance object. But, if there are to be any implementation parallels between the two in future Parrot, namespaces should become more class-like, rather than regressing classes to be more namespace-like.
Allison _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
