in reply to Changing API's of CPAN modules

Revisiting this issue: what if you want to have the same source module provide 2 versions of the same of the same API?

And how do you handle the case of methods themselves having changing API's?

For instance, for a particular module v1.5.1 might have a ::new method that takes one set of parameters and generates an object with a particular internal representation, but v2.0 might have a different set of inputs to the ::new method and an incompatible internal representation of the class object.

Replies are listed 'Best First'.
Re^2: Changing API's of CPAN modules
by GrandFather (Saint) on Aug 14, 2014 at 03:39 UTC

    Instead of having one module provide both APIs, you could provide a new module for the new API and either use the old module under the hood, or refactor the common code out of the old module and both variants of the module use the worker module under the hood.

    If your module is OO (::new implies it is) provide a different constructor for each API variant. Your module code can then use any applicable common code and people get to choose to use the new API if they want.

    Perl is the programming world's equivalent of English
[reply]
Re^2: Changing API's of CPAN modules
by Anonymous Monk on Aug 14, 2014 at 01:18 UTC
    sub new1 and sub new2? Cog - the original and Cog2 - the improved?
[reply]

In Section Meditations