Front page | perl.perl5.porters |
Postings from September 2011
On 09/07/2011 07:05 AM, Nicholas Clark wrote: > But what this means is that on any *previous* major release, any module > can load version.pm and as a side effect change core semantics everywhere. > Effectively, loading version.pm behaves like upgrading perl to a different > major version. At runtime. From any module's code. Loading version.pm in any release of Perl prior to 5.10.0 changes one and only one global behavior, and it is one that MUST be changed in order for version objects to function. This isn't a high level argument about purity of code or what can or cannot be changed by aftermarket CPAN modules. This is cold hard fact. The existing UNIVERSAL::VERSION code in any release of Perl prior to 5.9.whatever (when version.pm was imported into the core) has no idea how to handle version objects. From 5.6.0 onwards, there was some somewhat hacky code to try and compare v-strings, but otherwise UNIVERSAL::VERSION _only_ understood floating point numbers (or things that looked like numbers). That completely defeats the purpose of having standard parsing and comparison logic for version objects completely. I am increasingly regretting agreeing to make the change to version.pm; so much so that I am thinking of just changing it back on CPAN and letting the argument about what to do about blead go on without me. If you want the contents of Package's $VERSION scalar, get it via $Package::VERSION. If, however, you want what is equivalent to what that version will actually be used for comparison purpose, call the function Package->VERSION, which should return the stringified version object that would have been used has you issued Package->VERSION(0). And still, no on has fixed base's idiotic behavior. I have to go drive my daughter to school. Have fun storming the castle in my absence... John