David Manura wrote:
use Text::Balanced '1.95_1.96';
-davidm
I don't understand the scenario in which someone besides the module author would
ever use this. If I have understood this thread so far, the interface changed in version
1.96 and then changed back, and you want to support the poor souls who are using
the legacy 1.96 interface.
Not exactly. The current version on CPAN is 1.95. I'm working on 1.96 which cleans up (and breaks) this interface. Here's a snapshot of 1.96 (beta version):
http://math2.org/david/tmp/tb/
In fact, as seen in 1.96, I've overridden VERSION as suggested in order to support the dual interfaces: 1.87-1.95 (old style) and 1.96 (new style). "t/version.t" tests all this.
So, for a client to work under both the new and old versions, it might do
use T::B 1.87;
If 1.87-1.95 is installed, this works fine. If 1.96 is installed, it still works because T::B 1.96 silently switches to the legacy style interface.
-However-, sometime down the road (say v. 3.14) I may want to get rid of the legacy interface from the T::B code (e.g. for efficiency). If I do that and the user installs version 3.14, then all the code that tried to be nice and compatible will now die:
use T::B 1.87;
because T::B 3.14 cannot provide the 1.87 interface. This die may be unnecessary if the client code happens to work under both the old and new interfaces. Therefore, something like this:
use T::B '1.87_1.96';
is more precise because it says "The client code accepts either the 1.87 or 1.96 style interface." 3.14 will work now. In fact, the entire 1.87-3.14 range (and possibly beyond) will accept the above line.
My original plan for the '1.87_1.96' syntax did not have in mind simultaneously using the multiple-interface VERSION() trick. With the VERSION() thing now in place, the '1.87_1.96' syntax becomes less useful, but as shown above I believe it still can serve a purpose.
Assuming they listed the current version they were using in their source code, they are going to have
use t::B 1.96;
in there.
They aren't going to have a way-new skypie version phrasing, and apparently we care
too much about them to force them to adjust their installed code to the new interface.
I therefore repeat my recommendation that an overloaded VERSION could place
flags in the dynamic variable space with respect to caller(), which is available
within VERSION; with the adjustment that the flags get placed under the name space
of the module we are adjusting the interface of rather than under the caller's name space,
in case the caller needs a census of their name space.
No, I take that back, because it would break Pollute - style multiple include files.
The approach I currently use is what you do not recommend. How does the above T::B 1.96 source code break Pollute?
Pick
a name for your flags and boldly pollute your caller's package with them. Make
Text::Balanced::VERSION set ${caller().'::Text_Balanced_InterfaceFlag_Baz'} with
the appropriate behavior for how Baz is handled by the interface of the version
requested, and make the method that handles that version refer to the flag using
the same syntax.
One could even keep multiple versions as whole methods and dispatch them through a variable in caller()'s name space:
sub Text::Balanced::Blurf( eval{ goto &{caller().'::Text_Balanced_InterfaceFlag_Blurf'} }; $@ and warn "tsk tsk, Text::Balanced used without version" )
Interesting, though I think the T::B changes are too small to warrant this approach right now.
-davidm
