Alpha Modules and Perl's use Statement
I'm contemplating breaking a very well-established standard: Version arguments to Perl's "use" statement. The module writer is free to change the semantics of these, but despite the endless eccentricities you find on CPAN in other things, they rarely (never?) do.
So I'm having guilt feelings. Insecurities are coming out. I'm getting second thoughts. In this post I will handle these things the way many people do. Preach.
Consider a default module use like
use Marpa;
The standard (and almost universal) semantics is to load whatever version is out there. This works if you can assume that the modules you're using are well-behaved and upwardly compatible. Or if you have strict controls on the libraries in the environment in which you are running. But what if you are dealing with software which is avowedly alpha?
Certainly allowing the user to say "Just give me anything" is very much in the Perl spirit. And it's necessary in some cases. Programs in a test suite should not be fussy about the version of the software that gets thrown at them. Crashing and burning because of new versions of software is their role in life.
But with alpha modules, it's a poor default. So I'm thinking of having my alpha modules accept only two forms of the use statement, both with two arguments.
use Marpa 0.001_037;
The numeric version of the two argument form means gives me version 0.001_037 and version 0.001_037 only. Upgrades result in an error message.
use Marpa 'alpha';
The two argument form with the alpha argument means give me anything alpha or later -- in other words, anything at all. That's the equivalent of the "wide open city" default behavior. But here the user has asked for it explicitly.
What do I do with the one argument form?
use Marpa;
The one argument form gets you a multi-line error message which summarizes what I've just said.
This might make people think before including a dependency on my new, alpha, module. But is that a bad thing? Shouldn't alpha code turn off unsafe defaults? Perhaps other writers of alpha code should consider non-standard semantics for the use statement. It will help me with my guilt feelings.
I blog about Perl, with a focus on parsing and Marpa, my parsing algorithm based on Jay Earley's.
FAIL. This is like requiring users to say "
use Marpa 'no I really mean it'". Making your users' lives worse is not the best way to assuage your own guilt.I've got to say I don't like this. In the Ruby world 'gems' (like CPAN modules) can be versioned so that you can have multiple versions instaleld and each app loads exactly the version required. The result is a nightmare to maintain.
The Perl5 and CPAN communities have generally been pretty good about backwards compatibility. Dev releases on CPAN get uploaded with an '_' in the version, allowing the CPAN shell to ignore dev releases unless they're requested specifically. For stable modules, API changes generally happen with a deprecation cycle and maybe some warnings added.
By contrast, in the Ruby world people don't seem to care about backwards compatibility at all. A new gem comes out that has a completely different API and the assumption is that you'll just stick with the old version until you've changed all your code. It's a maintenance nightmare and the main reason I don't use Ruby more. I think it would be a shame to promote this kind of thinking in the Perl world.
Thanks for the feedback. Thanks especially to Grant for the case history of Ruby. It is interesting that there's "blowback" from tightening up version control -- module (gem) writers interpreted that as a permission to fiddle the API without worrying about backward compatibility, and things wound up worse not better.
In any case, I get the message. I will stick with the conventional
use Module versionsemantics.