in reply to Re: Re: How Many Modules Is Too Many?
in thread How Many Modules Is Too Many?

But this doesn't means that with this chunks of codes, that come from other modules to avoid requisites, I'm not adding new things! Generally this chunks of codes are revised, fixed and upgraded.

But note that here our policy of development is to always create a system not much dependent of others. 1st because our enverioment that we develop need to be easy to install, 2nd because it need to be portable for many OS, and dependecies make this harder.

For example, XML::Smart has his own parser, XML::Smart::Parser, that is a upgrade and fix of XML::Parser::Lite. Why that? Because XML::Parser, the main XML parser for Perl, uses 26 modules. But the biggest problem is not to load 26 modules, but this modules come from a lot of different distributions (XML::Parser need: URI, HTPP, LWP, libwww...), that need much more things to be installed. So, 1 dependency generally means more sub-dependencies.

History also shows to us that big dependencies make the probabiblity of bugs bigger, and is harder to fix them, but the biggest problem is the probability to have incompatibilities in the future with new versions. I know that, since I try to use less dependencies as possible, and I had this problem in less than 1 year with 2 modules.

Graciliano M. P.
"Creativity is the expression of the liberty".

  • Comment on Re: Re: Re: How Many Modules Is Too Many?

Replies are listed 'Best First'.
Re^3: How Many Modules Is Too Many?
by BigLug (Chaplain) on Jun 01, 2004 at 00:03 UTC
    The following post should be in reply to gmpassos' post above.
    The biggest problem with using CPAN modules is code redundancy. Lets say that we have a module for creating a menu on the console. That module has code built in for ANSI escapes rather than using the ANSI modules. So we've saved loading some modules and people would be happy.

    That's all well and good if all we want is a menu. However we also want to display a result message so we load the ANSI modules ourselves.

    So now we have the ANSI functionality twice!

    If the menu module documented that is contained ANSI methods we could, naturally, just use those. But consider this: We now want to use another module that displays a group of ANSI checkboxes .. and it was written by yet another developer so she's also included all the ANSI stuff in that module (to save people loading dozens of extra modules!)

    So now we have the ANSI functionality twice again!

    In situations where people don't want all the extra installation hassles with the extra modules, I'd encourage them to create bundles. Thus ANSI::Foo requires ANSI::Util rather than just replicating it's behaviour. But then there's Bundle::ANSI::Foo which installs all the prerequisites without too much user interaction.

    "Get real! This is a discussion group, not a helpdesk. You post something, we discuss its implications. If the discussion happens to answer a question you've asked, that's incidental." -- nobull@mail.com in clpm
[reply]

In Section Meditations