Re: Ivy.pm: name change? to upload on CPAN
On Wed, Nov 26, 2003 at 03:31:21PM +0100, Christophe MERTZ wrote: [Changing Ivy to Net::Ivy] BTW: I do not know if this discussion is still appropriate in the mailing list, as I am new on it. Let me know... I don't have an answer to your question about how to do it, but I do think that the discussion is appropriate to this list, as getting this list to work out the the best way making this change will help future authors. This won't be the last time someone asks the list this question for an existing module, and the recommendation is to make this sort of rename. Nicholas Clark
Re: Ivy.pm: name change? to upload on CPAN
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);
I prepared a mail yesterday, but did not send it, where I was asking
about this functiunal API. But you answered before I send you this
question! Just some more answers to Tim in a mail to come (about C libs
and perl).
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.
I will try and test it, but I am quiet confident now.
(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.)
Well I supposed there should not be other pbs!
Thanks a lot to both of you for your suggestions and your time!
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%.
[...]
Lincoln A. Baxter [EMAIL PROTECTED]
--
Christophe M.
RE: Ivy.pm: name change? to upload on CPAN
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).
Well, to be honest this is a dirty trick IMO, that can cause subtle
problems. Better to go the route that File::Spec went, and add a function
wrapper for the methods. (File::Spec::Functions autogenerates the functional
equivelents from the methods on demand).
However, this would just add more modification requirements to your code.
Assuming that the first arg to your functions is NEVER a descendent of
Net::Ivy (or Ivy whichever is your root class) when called in functional
form then the following should work ok:
sub init {
my $class = shift if (@_ and UNIVERSAL::isa($_[0],__PACKAGE__));
my (%options) = @_;
...
}
sub bindRegexp
{
my $self = UNIVERSAL::isa($_[0],__PACKAGE__) ? shift : $globalIvy;
my ($regexp, $cb) = @_;
...
}
Cheers,
Yves
Re: Ivy.pm: name change? to upload on CPAN
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]
