Dan Sugalski <[EMAIL PROTECTED]> wrote: > I think I'd rather have pre-defined names in the PMC library
Yep. I've abandoned the return structure thingy. There is now one fixed init call to get things running: for the PMC extension foo_pmc$(SO): int Parrot_dynext_foo_init(Interp *interp, int action, void *param) C<action> is SETUP or INIT with an appropriate structure hidden in C<param>. If we need somewhen an extended setup/init, we can provide additional interfaces hopefully. > The big issue is one of metadata. Its somehow a problem. But the HL compiler (writer) just knows, that e.g. F<python_pmc.so> provides all Python PMCs. These shared libs have to be written for a certain language and when some code needs this, the compiler will just emit the matching C<load_pmc> op. A bigger issue are IMHO the class enums. Current state is, that the C<load_pmc> op must be in the same sequence at compile *and* runtime. This could cause troubles, if a Perl6 program calls a Python lib and then a Ruby lib, both having a C<load_pmc> in the lib. OTOH there must be some "use ThisLib;" statements first, which are in one specific sequence. > We probably want some sort of metadata system on disk, though I'm > loathe to go that way. If we need these, they can be autogenerated by pmc2c.pl. Anyway, I have committed my current version. Its not a final thing, it needs more Configure support, base_vtables is still static and so on, and I really don't like the issues WRT the gloabals, which exist in parrot and in libparrot twice. Its simpler to discuss existing code and having big diffs against CVS isn't really nice ;-) leo
