in reply to Re: Which name for a new cpan module?
in thread Which name for a new cpan module?

I already uploaded two other modules Tk::Zinc and SVG::SVG2zinc. So I have now some little experience on it. However in the case of Ivy, the trad-off is between CPAN namespace pollution and preservation of our numerous existing applications. We can hardly get rid of 5 years of code, just to upload it to the CPAN. That's why I am looking for a wrapper technic or something similar to maintain the current Ivy.pm inhouse, while delivering a Xxx:Ivy on the CPAN.

You are right, the website is currently down, I pray it will be up again on Monday. Sorry for this.

  • Comment on Re: Re: Which name for a new cpan module?

Replies are listed 'Best First'.
Re: Re: Re: Which name for a new cpan module?
by Anonymous Monk on Nov 21, 2003 at 21:48 UTC
    That should be easy given you've properly designed your ivy modules. Make the switch to Xxx::Ivy, and upon `perl Makefile.PL' prompt (using ExtUtils::MakeMaker::prompt) users if they wish to install legacy Ivy module, which would do the neccessary mojo so your apps don't break ( if your modules are written well, all that should be neccessary is a
    #Ivy.pm package Ivy; use base 'Xxx::Ivy'; 1;
    ).

      (if your modules are written well, all that should be necessary is ... <snip>)

      That'll work if the current Ivy interface is via class/object methods. However, if the current interface is via exported functions/symbols, then the above won't automatically be enough: the functions from Xxx::Ivy will likely only be exported up to Ivy, when really it's Ivy's caller who wants those functions.

      dominus's ModuleBundle can shine light here, as can Exporter's export_to_level method.

      blyman
      setenv EXINIT 'set noai ts=2'
        Another option is namespace munging:
        package Ivy; # in Ivy.pm { no strict 'refs'; *{"Xxx::Ivy::"} = *{"Ivy::"}; }

        That should handle most exporting and inheritance issues by making the two packages equivalent...

        thanks for your enlightment

        Originaly Ivy.pm was only function based and it was only possible to use one Ivy bus. It has been extended so that this functionnal interface still works, but usually we are now using a class/instance interface style. Usually there is only one instance of Ivy bus. I think the main exception is when we developped some GUI applications plug-in's. In those plug-ins' a new part of the GUI is added as an external module, and this GUI part is communicating through new instances of Ivy.

        In my current knowledge of perl and according many responses to my quest, I am sure building a full wrapper is possible. The real point now is whether it is worth such complexity as currently this module is quiet simple to understand. My feelings are it does not deserve such complexity if the Ivy name could become a new root name in the CPAN.

        Any way, I will ask the question on the appropriate mailing list on the CPAN.

        Then there is always goto ;)