I will never trust Storable to use it again. If I could, I'd vote it off the 'Perl core' island.
Heh! You know, many of the porters feel the same way. It took a tremendous amount of effort to get it compiling and testing perfectly on all the various platforms that Perl runs on. Compiler idiosyncrasies make it particularly difficult to get right each time. Changing a preprocessor macro to work around the damage in one compiler made it break in another.
And it continues to soak up developer effort, as time goes by. On the other hand, it's nice to have a big hairy XS module lying around so people can point to and say "oh no! not again!" whenever someone calls for another large XS module to be pulled into the core.
• another intruder with the mooring in the heart of the Perl
| [reply] |
But I have no control over what version of the tool my application will encounter in the wild.
To a certain degree, this will be a problem with any module you use. Versions change, internals change, and incompatibilities creep in even when they aren't intended. The only way to be sure your application will work is to bundle specific versions of the modules it needs. This isn't so much a perl thing as a general issue with componentized software.
In the case of core modules, you at least have a simpler target. You can test against the specific perl versions you want to support. But even so, distributions will modify them, people will install newer versions for features they need, etc.
By the way, Storable rocks. It's massively faster than Data::Dumper, highly cross-platform when you store in network order, and as mentioned elsewhere the newer versions try hard to work across version and format changes. It was a great day for perl when we got a fast serialization mechanism in the core and I'd be very sorry to see it go.
| [reply] |
You can always identify your environment your application will run in. Take a look at CPAN, part of what it does is looking at what modules are installed and what versions. Depending on the config, it will upgrade or install other Perl packages as needed. If it did not, CPAN would be a little more than a fancy file copy utility.
Now if you don't want to work with Storable, that is fine, but what happens when another module that you depends on has issues because of different features from version to version? Are you going to curse that module too or are you going to do something about it?
Take a look at Module::Build and consider how it handles installing modules and maybe you can come up with a better solution than excommunicating Storable.
| [reply] |
