How to inject methods

[Austin Hastings]

Allison Randal wrote:
> 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.
>

One important part of Kakapo's model is that it gets in early. When 
fully involved, Kakapo serves as a run-time library for compiled HLL code.
 
To that end, much of the Kakapo initialization code runs very early in 
the program cycle - generally as early in the :init or :load sequence as 
is possible.

At that time, many classes are not fully initialized. One frequent 
problem I encountered was circular dependencies on initializations for 
PMC-level or Core-PBC-level code. (E.g., p6object, dumper, test::*).
 
The ability to compile a certain method into a namespace, and have that 
code automatically picked up by the PMC/Proxy/Class code has made a 
bunch of things simpler - in particular, it makes it possible to assume 
that if PMC Foo is up, then all the helper methods are up. Which in turn 
means that the helper methods can be used in the rest of the Kakapo code.
 
Say for example I want to use the ResizablePMCArray::bsearch method that 
is provided by Kakapo. (This is a bad example for a bunch of reasons, 
but it's good enough for now.) Pre-389, that's trivial: just make sure 
the code is loaded (Kakapo comes in a single big library image, so if 
any of it is loaded, all of it is loaded), and call @a.bsearch(...).

Given the 389 changes, that's no longer true. So how do I (or, since I 
can't even get Parrot 2.5 to build, how does Andrew) accomplish the same 
result?

1. How do we get a list of class methods on a PMC that may not be up yet?
2. How do we get a list of methods defined in a namespace? (For 
export/use purposes...)
3. Does namespace merging still work for Classes? (IOW: foo.pbc and 
bar.pbc both contribute :methods in namespace X)
4. Does namespace merging still work for PMCs? (IOW: foo.pbc defines 
Integer::is_prime :method, does that get added to the Integer objects 
after loading foo.pbc?)
5. Is there some kind of PMC onload feature?
6. Is there some kind of autoload for PMCs? (Please keep in mind the 
PMCproxy vs. Class issues when you start to type "find_method".)
7. IIUC, replacing a method is a MOP level activity. Does p6object have 
a protocol for this?
7a. Does that protocol work on PMCs?
8. Is there a way to register methods for pickup by PMC proxy?
9. Is there a way to modify the method list of a PMC proxy class after 
instantiation of some elements? (Hash, for example, gets used really, 
REALLY early. So adding/replacing methods to Hash via the Class 
interface will require this.)
10. What is the officially approved mechanism for dynamically compiling 
a method at runtime (well after initialization) and adding it to a 
class? (This one seems straightforward, but what namespace should the 
new method be compiled into?)
11. Is there any difference for VTABLEs? For multi-methods?

=Austin
=Austin