in reply to How can I (safely) use packages of the same name but different versions?

Problem 0: your technique doesn't work at all. Modifying @INC won't change what function is called, it only affects require and use.

I think you need to slow down - what's the real problem you're trying to solve? Are you trying to create a dynamic plugin system?

-sam

  • Comment on Re: How can I (safely) use packages of the same name but different versions?

Replies are listed 'Best First'.
Re^2: How can I (safely) use packages of the same name but different versions?
by xevian (Sexton) on Mar 11, 2008 at 20:55 UTC
    I'm sorry I forgot to mention that ALL function calls go through this universal autoloader, and if the function can not be found in the symbol table it figures out the package name with a regular expression, requires the package, and then calls the function: 
    # figure out package name as $pkg
eval "require $pkg;";

    [download]
    The real problem is similar to a dynamic plugin system, but I do not want the residual effects of loading a package (permanently modifying the symbol table) that exists elsewhere.
[reply]
[d/l]

      The real problem is similar to a dynamic plugin system, but I do not want the residual effects of loading a package (permanently modifying the symbol table) that exists elsewhere.

      How do you intend to avoid permanently modifying the symbol table? Why would you want that, anyway? If you don't permanently modify the symbol table won't you have to reload the entire module on each function call?

      -sam
[reply]
        That's why I'm asking - I'm not sure how I intend to do it :)

        I want to do this because I do not want older code (read: default install location) to be calling functions in a newer codebase just because something called a function in the new codebase (and thereby required the new modules, replacing the symbols that existed).

        I.e. 
        My::Package::foo();
...
NEW::My::Package::foo();
...
My::Package::foo();  # this one I want to use the old codebase always,
+ even if someone called the NEW:: version at some point.

        [download]
[reply]
[d/l]
Re^2: How can I (safely) use packages of the same name but different versions?
by Errto (Vicar) on Mar 12, 2008 at 16:05 UTC
    I don't know anything about xevian's situation, but one place where I can see something kind of like this come up is when there are backward compatibility problems. For example, let's say DBD::XYZ version 1 only supports XYZ database version 1, whereas DBD::XYZ version 2 only supports XYZ database version 2. If your code, for whatever reason, might have to connect to instances of different versions of XYZ within a single program, you're going to have a problem.
[reply]
[d/l]
[select]
      I've heard rumors that Perl 6 will solve this problem. Personally I don't think it's going to be all that helpful. New versions are released for a reason - leaving old code using old versions of their dependencies is only going to get you so far. Your example is a good one - if XYZ v1 and v2 are both being used to access the same physical database then you've likely got a problem that Perl alone supporting multiple version loading can't solve.

      I haven't had a chance to try it yet, but I thought Erlang's facility for running multiple versions of code long enough to do a seemless cut-over sounded smart. Since everything in Erlang is a networked server the system starts up the new version and starts sending all new requests to it. Once the old version is done handling any lingering requests it gets shutdown.

      -sam

[reply]
        The database thing happens to be a non-hypothetical question for me. I'm not giving details because my actual situation involves Java, not Perl, but the concept is the same.
[reply]

In Section Seekers of Perl Wisdom