On Tue, Jan 20, 2004 at 10:07:43PM -0500, David Manura wrote: > In consideration of what Fergal said, should every public method or > function in a module be individually versioned? So, when I do > > use Text::Balanced qw(extract_multiple extract_codeblock), 1.95; > > this could (under new semantics) assert only that those two functions have > the same interface and expected behavior as the corresponding functions in > module version 1.95. If a future version of Text::Balanced (e.g. 1.96) > adds or changes the interface/behavior of other functions, my code will > still accept the new module. Only when extract_multiple or > extract_codeblock themselves change interface/behavior would my code reject > a new module version. There is no need for my code to provide an > acceptable version range; that is the module's responsibility to deduce. > (OO-like modules must be handled by a different mechanism.)
It may be worth it in some cases but perhaps if the functions are so unrelated that they can change independently they should not be in the same module. Making Text::Balanced::Multiple::extract() and Text::Balanced::Codeblock::extract() would then allow you version them with the module. There's nothing to stop you still making them available to export from Text::Balanced. > Consider further that another author comes out with a module named > Text::Balanced::Python having the same interface as Text::Balanced 1.95 but > whose extract_quotelike extracts Pythonic quotes rather than Perl-like > quotes (i.e. differing behavior). I haven't considered how useful it would > be to express this relationship in the versioning metadata, but that might > be a further direction. This resembles (OO) interfaces, but I believe the > versioning considerations make it different. That is exactly what Java's etc "interfaces" do. So interfaces are what you want rather than versions however it might be useful to be able to specify the version of the interface. This is getting very far away from anything that might realistically happen... F
