Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re^4: On the rejected additions to List::Util

by ysth (Canon)
on Apr 29, 2009 at 06:32 UTC ( #760815=note: print w/replies, xml ) Need Help??


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

Ah, but L::U caters specially to numbers by having min and max, as well as minstr and maxstr. Why not mean() too?
  • Comment on Re^4: On the rejected additions to List::Util

Replies are listed 'Best First'.
Re^5: On the rejected additions to List::Util
by lodin (Hermit) on Apr 29, 2009 at 11:29 UTC

    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

Re^5: On the rejected additions to List::Util
by mr_mischief (Monsignor) on Apr 29, 2009 at 13:24 UTC
    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".

      Anything added to "core" is bloat by definition; sometimes it's just a minor bump, other times addition is a cancerous tumour. I do like the qualified phrase "not bloat too much".   ;-)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://760815]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (4)
As of 2021-10-21 08:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My first memorable Perl project was:







    Results (83 votes). Check out past polls.

    Notices?