Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re: How do you do multi-version modules?

by Corion (Pope)
on Oct 13, 2012 at 23:11 UTC ( #998884=note: print w/ replies, xml ) Need Help??

in reply to How do you do multi-version modules?

when a user says: "use module 1.0.0", and I'm working in module "2.0.0"? My 2.0.0 module would never get called as far as I can

What have you tried so far? What evidence do you have that supports your assumption?

The easy way to do that is to separate "module version" and "API version", and have the use line pass the API version as parameter. I recommend making the main module just a stub module and having "::API*" modules as submodules that get loaded resp. instantiated depending on what the user wants.

For example, a module could implement API1 and API2 in the following structure:

package My::Module; use strict; sub import { my ($class, %args) = @_; ... # Dynamically load either My::Module::API1 or My::Module::API2 };
package My::Module::API1; # The old API
package My::Module::API2; # The new API

User code would then use it in the following way:

use My::Module api => 'API1'; ...

Look at require and/or use to see how to do dynamic module loading.

Comment on Re: How do you do multi-version modules?
Select or Download Code
Replies are listed 'Best First'.
Re^2: How do you do multi-version modules?
by perl-diddler (Hermit) on Oct 14, 2012 at 01:10 UTC
    That would defeat the purpose of having 1 module handle both.

    I don't want to use multiple files for the same module -- duplicating code is a bad practice.

    One of the reasons I tend to put many modules in 1 file during development, is to find places to look for common code to apply reductions to. Only after some package has sat in my file doing nothing useful (other than providing it's function) other than than taking up useful space in my file.. I consider splitting it off... I.e. it's so far out of my head space, because I'm just "using the code", that it's not changing, and it's presence in the file is now a bother ... time to split it off and take it as a library component...OR...that might be too much of a bother...until I'm working on another program that wants to use the module...that's when I really work on splitting things...

    But I would think I had too many routines shared between the versions. I was only thinking of forcing a different parameter order on 1 routine -- would you really think it a good idea to duplicate hundreds of lines just to change a few?

      Maybe you want to reuse parts of ::API1 in ::API2, then? It's only you who claims that you have to duplicate code between the modules. Maybe having a preconfigured API "object" which contains the default parameters would be an option too, if the "API" only consists of default parameters.

      This has nothing to do with putting many modules in one file. You've already been advised against that, but this discussion is far besides the point.

      You don't have to put different packages in different files, only when you need to make them available to use from other files. SOAP::Lite comes to mind as a module where it exhibits much different behavior depending on what's needed (eg, do we use 'xsi:null' or 'xsi:nil' for this version of XML Schema?

      SOAP::Lite might be a bit of an extreme example, as they pack a *lot* into one file. (I count 28 package declarations currently, and it looks like more might be dynamically generated; I remember bugging BareBones Software for *years* about marking packages in automatically generated list of functions so that I could use it to find my way around the file).

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://998884]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (7)
As of 2016-05-06 16:21 GMT
Find Nodes?
    Voting Booth?