Re^2: How do you do multi-version modules?

[perl-diddler]

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?

[Corion]

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.

[jhourcle]

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).