This has been pending for a few days, but since Leo's been digging into
things it's time to address it.
We need parrot to be able to load in shared libraries, of course -- both
to get access to system libraries and to load up our own library code on
the fly. We'd also rather not have to have separate .so/.dll/.exe files
for each PMC class, opcode library, and Parrot function library, as that
can get unweildy very quickly, and potentially exhaust the file descriptor
pool on some OSes. (As well as being a massive headache to manage if a
high-level extension has multiple PMC classes written in C, an opcode
library or two, and some parrot functions written in C)
So, it looks like a shared library can have the following resources in it:
*) Native routines that must be actively imported
*) Parrot subs/methods
*) PMC classes
*) Opcode libraries
And, to make it more interesting, we don't want these things all
instantiated when we load in a library -- they need to be instantiated on
demand. So....
The logical solution seems to be that libraries should, when loaded,
register the parrot-aware stuff (parrot subs, pmc classes, and opcode
libraries) which can then be instantiated or imported as the loading
program needs. The already-specified behavior for library loading can be
leveraged for this, which is nice.
The sequence, then, is:
1) Code issues a library load call
2) Parrot dynaloads the shared library
3) The shared library init routine is called
3a) Shared library calls pmc_register to register each PMC class it has
3b) Shared library calls oplib_register to register each oplib it has
3c) Shared library calls class_register to register each class it has
4) The library loader makes sure the class/pmc/oplib it wants is
instantiated
A class, rather than a PMC class, is a HLL OO class or package. Basically
a namespace, set of functions and methods, and possibly some class
metadata.
Before I go any further, I want to make sure this makes sense to everyone.
Dan
