Sadly it turns out to be not quite that trivial because the interface
has this kind of style
$obj->foo($bar);
Ivy::foo($bar);
But even that's not a big deal. If the functions are exported then
do things like:
use base Exporter;
our @EXPORT = @Net::Ivy::EXPORT;
if it's not then do something like
*$_ = \&{"Net::Ivy::$_"} for (qw(foo bar baz func names));
Or do both. Either way, it's just a bit of "plumbing".
(If the interface has deeper issues that'll cause problems then
I'd be tempted to say it's broken and Ivy.pm should have more hacks
for legacy support and Net::Ivy should have a better interface design.)
Tim.
On Tue, Nov 25, 2003 at 04:07:53PM -0500, Lincoln A. Baxter wrote:
> As if Tim's opinions don't carry a huge amount of weight already, I will
> add my $0.02 and agree with him 100%. Put it in the Net:: name space
> and Net::Ivy, and provide the 3 line rewrapper for your internal use,
> that is not at all complicated for error prone.
>
> On Tue, 2003-11-25 at 12:04, Tim Bunce wrote:
> >
> > It's a single module implementing a class. The wrapper ought to be no
> > more complicated than:
> >
> > package Ivy;
> > use base Net::Ivy;
> > 1;
> >
> > Hardly error-prone.
> >
> > > Do you have some suggestions?
> >
> > I'd suggest uploading as Net::Ivy and bundling an Ivy.pm as a wrapper.
> --
> Lincoln A. Baxter <[EMAIL PROTECTED]>
>
