|Public Scratchpad||Download, Select Code To D/L|
Should Perl be better defined?
Pre vs Post Incrementing variables got me thinking and reading about the order in which operators evaluate their arguments and what they return.
This isn't the first time. I have read and contributed to various threads/discussions that hinged and sometimes came unhinged (at least some of the participants did) on understanding and misunderstanding of what operators return and the order in which they evaluate their arguments. They often begin with some surprising finding rooted in the discrepancy between what people think perl does or should do and what it actually does. While there is usually some reference to the documentation, it is sometimes ambiguous or silent on the issue and examples of what perl does are presented.
Discussions of these aspects of Perl/perl can bring out strong opinions and vigorous debate. Thus I conclude that they do not remain undefined because nobody cares about them.
So, I wonder why so much remains undocumented and whether there are advantages that outweigh the disadvantages.
I recall a post by Argel, and some followups. They impressed me at the time and they make me much less certain than I would otherwise be, whether more complete definition of Perl/perl would, in fact, be a good thing.
Yet, it seems less than ideal that so much of what perl does is undefined, leaving one with little but observation of perl itself (perl does what it does, after all) and a collection of more or less detailed, more or less abstract and more and often less accurate descriptions of what it does and why it does it.
What perl does is complex and can be difficult to understand. People often seek simple models and abstract descriptions that explain the common cases without the burden of learning all the details. These simple descriptions, if they are not too inaccurate, can be very helpful to using perl and progressing towards a more complete understanding.
One of the problems of simply studying perl to learn what perl does is that there is no distinction of the essential behaviors (what makes Perl/perl the great tool that it is) and the mere implementation detail - just one of many ways that the essential behavior could be achieved. But, maybe it is wrong to try to distinguish between essential behaviors and implementation details.
Maybe it is best to accept that perl is what it is and the documentation is only a guide. If there is a discrepancy between what the documentation says perl does and what perl actually does, maybe it is always perl that is correct and the documentation that is wrong.
In this case, perl will never have a bug merely because it does something different from what the documentation says it does. The only basis for deeming a behavior a bug would then be there is only perl as it is, with some documentation as a loose guide and the right thing to do is to study perl rather than study the documentation.
Many modules define a package global variable $VERSION. The value of this variable may be used by several functions outside the module. The behavior of these functions may influence how module authors choose to set this variable.
Where is $VERSION used?
Two forms of the arguments to use include versions:
- use MODULE VERSION
- use MODULE VERSION LIST
In both cases, after the module is loaded, the VERSION method of the module is called, with the given version as argument. The default VERSION method, inherited from the UNIVERSAL class, croaks if the given version is larger than the value of the variable $Module::VERSION.
It is, therefore, important to understand how UNIVERSAL::VERSION compares version numbers.
The documentation for UNIVERSAL::VERSION says:
VERSION will return the value of the variable $VERSION in the package the object is blessed into. If REQUIRE is given then it will do a comparison and die if the package version is not greater than or equal to REQUIRE.
VERSION can be called as either a class (static) method, an object method or a function.
It doesn't say how UNIVERSAL::VERSION compares the versions. Being unspecified it may be inappropriate to depend on any particular behavior for comparison. None the less, one can look at existing implementations to see what they do.
A relevant post from John Peacock (author of version.pm) from Oct 2008. Note in particular that he says the version specified as an argument to use must be unquoted and must match the pattern /\d+(\.\d*)?/ - anything else is passed as an argument to the module's import method. But perldata contradicts this saying of v-strings that "Such literals are accepted by both require and use for doing a version check." My testing of perl 5.10.0 is consistent with the perldata description rather than John's version. It may be that older versions of perl worked as John described in Oct 2008.
The v-string arrived with perl 5.6.0. The v-string is
Should I use the version module?
Development of the version module is ongoing. John Peacock is preparing a new release for the upcoming (as of July 2009) perl 5.10.1 release.
If you use floating point version numbers (e.g. our $VERSION = 1.02;) then there is no need to use the version module.
If you use perl 5.10.0 or later, the functionality of the version module is built-in - there is no need to use the version module.
If you use versions of perl before 5.10.0 and you want to use "extended" version strings (v-strings, like v-strings but quoted or quoted strings with digits and more than one decimal point) then you can use the version module to achieve consistent results across versions of perl back to some older version of perl.
The package global variable $VERSION may be used by:
- UNIVERSAL::version (I think it was - this may be what is called by use and require)
Colorize the Saints