On 3/8/07, Smylers wrote:
In Perl 5 if you rely on a feature (or bugfix) from a particular version of a module you can specify that version and the code will continue to work with future versions -- which is a reasonably pragmatic approach, effectively saying "until proven otherwise I'll presume that any future releases of this module won't break this functionality".

I think that looking at versions from the perspective of the person using the module is the wrong way around: as you point out, when I write a program, I have no way of knowing whether future versions of some module will continue to work (I just assume they do and hope for the best) -- however, the author of the module should know! So it should be the *modules* that specify compatible version ranges, not my program.

And if you are using my program, I likely have no knowledge or control of what versions of what modules you might be running. Instead, I ought to specify what version of the module I wrote my code against (that's one thing I can know for sure); future versions of the module should then themselves specify which previous versions they are compatible with.

        module Foo:<2.3.4 cpan:JSMITH>
                does versions(0.8.0..1.2.2, 1.2.4..2.3.4);

In this example, Foo has been pretty compatible since v0.8, but it skips v1.2.3, let's say because that version had a bug so it wasn't really compatible (even though it probably said it was).

My program would say (coining "used" for the sake of example):

        used Foo:<2.0.0>;

to indicate the exact version of the module I used to write my code. Then it doesn't matter whether that exact version is available as long as there is some module that advertises itself as doing Foo:<2.0.0>. (As determined by the modules, or by Perl, or by the Parrot Library Management System.)

Of course, I would still need to be able to specify details such as "but don't use Foo:<1.2.3> even though it claims to be compatible, because really I know it's buggy".

This would also allow for modules that are compatible not only with other versions of themselves, but also with other modules of a different name. (If your module provides the Foo interface, why not just name it Foo -- especially since you can choose an authority to carve out your own space in the Foo universe? You should, of course, unless your module also is compatible with module Bar. It can't have two names, but it can advertise itself as being compatible with two or more other modules.)


Reply via email to