Michael G Schwern wrote: > Why can't it load version.pm behind the scenes rather than duplicating it in > universal.c? (I realize I'm probably opening a can of well sealed worms)
Because that leads to a messy bootstrapping problem, since we can't guarantee that version.pm is built and ready to be loaded by the time the first module in the stack calls UNIVERSAL::VERSION (since that happens any time someone passes a minimum version to 'use'). I don't even know if it is possible to build version.pm under the same constraints that other dual-life modules can cope with. > The idea of having a CPAN module which cannot upgrade the core version makes > my feet itch. It sounds like it means going back to the old days where the > only way to upgrade a module is to upgrade Perl. The version.pm situation > makes it even more absurd because it sounds like you have the potential for a > newer CPAN version to be installed onto an older Perl (without version.pm > built in). Thus I could install the latest and greatest CPAN version.pm 2.13 > onto 5.8.8 but with 5.10 I'll be stuck with 0.70 forever. > > Stop me if this isn't the case. Yes, and no. Pretty much as soon as v5.10.0 gets to the Release Candidate stage, version.pm goes to 1.000 and development of new features stops. There won't be anything but bug fixes. Any itch I may have to use version objects in new and unusual ways happens in child modules (e.g. version::Limit or the not publicly available version::Math). The version.pm module is designed quite specifically to be set in stone at some point, yet allow full inheritance to extend it. And, if I _really_ had to fix a bug in version.pm that would require replacing the behavior in the core Perl, I could just change the Makefile.PL/Build.PL to support that. The bootstrapping problem doesn't prevent me from replacing the core version objects with a new implementation *after* Perl's startup... John
