First, for your command line switches, take a look at Getopt::Long. You can call the GetOptions function in a BEGIN{} block before loading modules with use. That will allow you to influence module loading with the command-line switches. G::L is shipped with perl, so there should be no hassle using it.

Why do I mention modules?

Your desire for overriding subroutines can easily be handled in OO Perl. You can make the ordinary case a base class, and subclass that to override. Having your data handling tucked away in modules which define the methods which apply to particular types of data allows you the flewxibility of reuse.

You could just write your subroutines to look at some state set by switches, but that strategy is brittle and doesn't scale well.

The if.pm module is very helpful for conditional module loading.

Do be aware that when calling a method, an extra first parameter is introduced: the class name, when calling it as a class method (or an object when calling the same sub as an object method).

As for the command line, I'd just use the -MFoo=bar syntax, to load the master module (Foo, file "Foo.pm"), and use the parameter ("bar") to actually load the submodule (Foo::bar, file "Foo/bar.pm"). Just like B/O do. For example, the command line switch -MO=Xref loads the module O, calls its import with parameter "Xref", which in turn loads B::Xref. So, you know where to look for an example implementation... :)

Actually you can also take a look at File::Spec and AnyDBM_File too, to see how those modules dynamically change their behaviour by loading a backend module, and then "patch themselves". That way your code can be oblivious of what backend is actually being used.

If that's too advanced to implement for your taste, you could instead simply use a global variable to store the package to use in the method calls, like

$pkg = "Foo::bar";
my $rate = $pkg->rate('basic');
[download]

$calculator = Foo::bar->new;
my $rate = $calculator->rate('basic');
[download]

Finally, you could have the base module export its functions, and have those refer back to the backend methods. Your code could simply call rate('basic'), which would invoke the function Foo::rate, which in turn would call Foo::bar->rate('basic'), which in turn could be inherited from Foo::Base, a class which you can actually implement inside Foo.pm.

Let me know if any of these ideas appeal to you, so I can bother with actually fleshing it out a little.

Not a answer, but a side bar.

sub rate {
   return 50 if $_[0] eq 'basic';
   return 150 if $_[0] eq 'bronze';
}

$rate = rate($package);
[download]

could be written as

my %rate = (
   basic  => 50,
   bronze => 150,
);

$rate = $rate{$package};
[download]

or

{
   # %rate is private to rate().
   my %rate = (
      basic  => 50,
      bronze => 150,
   );

   sub rate {
      return $rate{$_[0]};
   }
}

$rate = rate($package);
[download]