Folks,
I know everyone's got their own opinions on yanking functions (or not) from
the core interpreter image, but I'd like to remind everyone that this is
the *internals* list, not the language list. Our primary purpose is to
build a system that runs Perl fast and provides a platform others can
leverage off of to make perl run other places. Structural changes made here
should (one might go so far as to say must) be completely invisible to your
average programmer writing a perl program. If it's decreed that fork is
just there without having to do something special, then it will be no
matter what magic needs to be done.
Whether a particular function or set of functions (heck, even all the
functions) is linked directly into the main interpreter image or loaded in
on demand is an implementation detail, and one that should be irrelevant to
pretty much everyone but us and those intrepid souls that will write
guts-level code. If it turns out to be a win here behind hte curtain,
great. If it isn't that's fine too--we just won't do it. And if we later
decide it was a nice idea that didn't work then we can change it.
Our goals are:
*) Make perl run fast
*) Make Perl portable
*) Build a codebase that we don't have to overhaul again for a while
We have some time here. We can (and will, I expect) just try it as part of
one of the alpha or pre-alpha releases. If performance is unacceptable then
we'll fix it, and if we can't fix it well enough then we just won't do it.
It's far to early to get so... enthusiastic about it, though.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
