How to inject methods

[Allison Randal]

On 6/28/10 4:29 PM, Austin Hastings wrote:
>
> 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.

PMC/Proxy/Class hasn't been picking up methods stored in the namespace 
for a long time. When Jonathan and I revamped the object implementation 
in 2007ish, we changed all method lookup to go through the class object. 
This included a small hack for initialization purposes where methods 
added before the class object existed were temporarily stored in a 
separate hash cashed as independent metadata in the NameSpace object 
(but not actually stored in the accessible name keys of the namespace). 
That method hash is copied into the class object as soon as the class 
object is created (still is, that hasn't changed).

The extra copy of the method that was stored in the namespace (that is, 
as a regular globally accessible named key in the NameSpace object) is 
entirely irrelevant to the process of loading methods into the Class, 
and has been for years.


So, I'm confused here. I need specific code examples of what worked 
before that doesn't work now.

The code changes for TT #389 were really, really, really tiny. 6 lines. 
Really. See r45827.

> 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(...).

I can't see why that doesn't work now.

> 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?

What do you mean by "may not be up yet"? Do you mean a list of methods 
that will be part of the class object, but at a point too early in the 
initialization process for the class object to exist yet? They are 
stored in the separate method cache until the class object is created.

> 2. How do we get a list of methods defined in a namespace? (For
> export/use purposes...)

You can get a hash of the methods defined in the *Class*, by calling the 
'inspect' vtable function or 'methods' method on the class object.

> 3. Does namespace merging still work for Classes? (IOW: foo.pbc and
> bar.pbc both contribute :methods in namespace X)

I'm not sure what you mean by namespace merging. There hasn't been any 
change in the behaviour of defining methods in the class or inserting 
methods into a class at runtime.

> 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?)

No changes there.

> 5. Is there some kind of PMC onload feature?

Something other than :load or overriding the init or init_pmc vtable 
functions?

> 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".)

Do you mean a piece of code that gets called when no method of the 
requested name exists? No, the feature isn't baked in at the moment. 
Overriding 'find_method' should make it possible, but there may be a 
lingering bug or two there, and if so I'd like the details of the 
failure so we can fix it.

> 7. IIUC, replacing a method is a MOP level activity. Does p6object have
> a protocol for this?
> 7a. Does that protocol work on PMCs?

Patrick or Jonathan can answer that for p6object.

> 8. Is there a way to register methods for pickup by PMC proxy?

No changes there. What were you doing before?

> 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.)

Not at the moment. But it's a somewhat arbitrary restriction and could 
be lifted if a good case were made for why it was needed.

> 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?)

Compile the code in the usual way (compreg, etc), and then add it to the 
class with add_method.

The namespace is completely irrelevant to the method. Seriously, you can 
compile a method in any namespace, add it to the class using add_method, 
and the namespace of the original compile will be completely ignored.

> 11. Is there any difference for VTABLEs? For multi-methods?

Vtable overrides (subs or methods with :vtable), have their own 
independent cache stored as auxiliary metadata in the namespace before 
the class is created. They are inserted into the class object as it is 
created.


This conversation is beginning to make me feel guilty that we didn't 
immediately separate class-name declarations from namespace-name 
declarations. It seemed like a good idea at the time, since people were 
accustomed to defining methods by the shortcut of simply dumping a 
.namespace directive at the top of a bunch of PIR sub definitions with 
:method, and since Perl 6 had hybrid submethods that had some of the 
behaviors of subs and some of methods. But, it's looking like it would 
have been a lot less confusing if we had either required the :class to 
be specified on each .sub, or created a new .class directive to be used 
in place of .namespace.

Allison