The hard difference, Leo summed up - we need a way to deal with dynamic pmcs that depend on each other. If I had a bunch of unrelated pmc's (like the Foo example), I'd be done already.
For simple dependencies, you could just force them to be loaded in reverse order, or, I suppose, have a load of a child force a load of all its parents.
For the morphing types, like Perl* and Tcl*, where you have 4 class definitions that all reference each other, you really need to have a way to bundle up those pmcs into a single lib, so instead of doing a loadlib of "TclFloat", "TclString", etc, I would do a single loadlib "TclPMC".
I'm very short on implementation ideas, though.
Regards.
On Wednesday, April 14, 2004, at 03:25 PM, Dan Sugalski wrote:
Seems we've some issues with static vs dynamic pmcs. Could someone take a few minutes (nudge, nudge, Will :) and list out the issues? I'd like to have the build process for static and dynamic PMCs be identical which we're not at yet, so this'd seem to be a good time to do what we have to to make it so.--
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Will "Coke" Coleda will at coleda dot com
