http://qs321.pair.com?node_id=760736


in reply to Re: On the rejected additions to List::Util
in thread On the rejected additions to List::Util

The module author determinate what belongs to the API.

Normally, yes. Does that still apply to core modules like List::Util? I'd always assumed that authors gave up a certain measure of control in exchange for having their module distributed as a fundamental part of the Perl standard library.

As you pointed out all rejected functions are already in List::MoreUtils. I'm strictly against duplicating every function in all modules.

The question is more why List::MoreUtils has to exist at all. Why not put the functions in List::Util and do away with List::MoreUtils completely? Isn't it simpler and cleaner to have one utility module instead of several?

The other issue is that List::MoreUtils is not a core module. That means there is no guarantee it will always be available. This is a big problem for many people. We don't all have root on the machines our code runs on. We might not even have access to those machines, in which case we are unlikely to have the clout to insist that third-party modules are installed on them. If functionality is not in the core libraries, we might be forced to reinvent these wheels again and again and again. How is that good?

I like clean simple API's much more than a collection of oneliners.

Do you think it's cleaner to have all the oneliners copied and pasted into the start of every script that uses them? Do you think it's simpler to have to remember which of several list utility libraries each basic function is in?

  • Comment on Re^2: On the rejected additions to List::Util

Replies are listed 'Best First'.
Re^3: On the rejected additions to List::Util
by mr_mischief (Monsignor) on Apr 28, 2009 at 21:18 UTC
    The arithmetic mean, geometric mean, mode, median, etc of a group of numbers are not properties of a generic list of scalars. There is no meaningful arithmetic mean of qw( Porculus mr_mischief metaperl ikegami ) for example. Those are statistical properties, and I believe rightly belong in the Statistics name space rather than the List name space.
[reply]
[d/l]
[reply]

        minstr and maxstr are well defined for qw( Porculus mr_mischief metaperl ikegami ). meanstr is not. (The median though could be defined for odd-sized lists of strings.)

        The thing is that Perl has different comparison/ordering operators. So there are two natural ways to define min and max in Perl corresponding to the two sets of ordering operators. Had there been only one version of "greater than" then I figure there would have been only one function for min resp. max.

        lodin

[reply]
[d/l]
[select]
        Well, for sake of absolute purity the minimums and maximums might be better placed in the Statistics modules, too. It's a little late to make that decision pragmatically, since L::U is standard and already includes them.

        Where to draw the line on what to include and what not to include can be a difficult one. Second-guessing the maintainer about what they are willing to maintain and not maintain according to their vision for the module doesn't seem very productive. If someone has a clear and sensible argument for additional functionality, then I'm sure it would be considered along with other factors.

        It would take quite an argument, I think, to argue adding functionality to a core Perl module that already exists in multiple CPAN modules. One would have to convince the maintainer that the additional code is ultimately useful. It would have to meet a common need. It can't spread development and testing time too thin. It can't bloat the core distribution too much. Any additional functionality has to fit with the theme of the module as understood by the maintainer. Ideally, someone wanting additional functionality would present a well-suited patch in the style of the existing code along with an argument covering each of these points.

        There's still not a guarantee what the maintainer of a module will agree to do. After all, that person or team has to maintain those changes even if they accept the patch. It would go much farther than just saying essentially "I can foresee other operations on lists, and all of them should be in a module called List::Utils".

[reply]
Re^3: On the rejected additions to List::Util
by ysth (Canon) on Apr 29, 2009 at 05:08 UTC
[reply]
Re^3: On the rejected additions to List::Util
by borisz (Canon) on Apr 29, 2009 at 16:14 UTC
    You do not need root access to use modules or install them. It is just a little more painful to install.
    The question is more why List::MoreUtils has to exist at all. Why not put the functions in List::Util and do away with List::MoreUtils completely? Isn't it simpler and cleaner to have one utility module instead of several?
    One reason is I use List::MoreUtils for years and do not plan to change all scripts. But a bit overdone, you ask to fold CPAN into the core? A lot of my scripts use XML::LibXML and DBI and HTML::Template. I like to get them into the core too.
    Do you think it's cleaner to have all the oneliners copied and pasted into the start of every script that uses them? Do you think it's simpler to have to remember which of several list utility libraries each basic function is in?
    Often yes, since I have to read learn every silly simple function. Sure it is not a problem, if I add some simple handy functions to my script as well. I even like the split between the core functions and the handy glue. Or you could use List::AllUtils, but thats again not in the core.
    Boris
[reply]

In Section Meditations