On Tue, 2003-11-25 at 23:00, Tim Bunce wrote: > 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".
Well I started the change in the original module (Ivy.pm => Net::Ivy.pm) and "codeing" the new Ivy.pm as a wrapper but then I got another problem. All functions in the module can be used as method; the trick used to do it is to use the __PACKAGE__ "variable" the following way: sub init { my $class = shift if (@_ and $_[0] eq __PACKAGE__); my (%options) = @_; ... } # or : sub bindRegexp { my $self = ref($_[0]) eq __PACKAGE__ ? shift : $globalIvy; my ($regexp, $cb) = @_; ... } The problem appears now, when using construction such as : use Net::Ivy; Net::Ivy->init(-appName => "foo", -loopMode => "local"); # is fine! #but when using the old construction with the wrapper: use Ivy; Ivy->init(-appName => "foo", -loopMode => "local"); Error in Net::Ivy::init: option -appName is mandatory at -e line 1 # because now, ref($_[0]) eq __PACKAGE__ is false Do you have suggestions? (I could find a correction, but not sure it will be really a good one). BTW: I do not know if this discussion is still appropriate in the mailing list, as I am new on it. Let me know... -- Christophe M.