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.
