Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re^3: The Bad, the Ugly, and the Good of autovivification

by ihb (Deacon)
on Apr 11, 2005 at 16:47 UTC ( #446671=note: print w/ replies, xml ) Need Help??


in reply to Re^2: The Bad, the Ugly, and the Good of autovivification
in thread The Bad, the Ugly, and the Good of autovivification

Overlooking the smug tone; there's a limit of where people don't want to rely on non-standard modules. Small things like this get reimplemented over and over again, because it's "so small" and it's "not necessary to use a module for that". When a module become standard, that attitude changes somewhat.

Now, I'm not saying that this particular module should be in the standard library, but I definately think your categorical rejection of it lacks. Slightly overlooking that the choice to include a module in the standard library seems somewhat arbitrary; many of the newer standard modules are "Perl close", i.e. they solve a problem that has to do with Perl the language, and many others solve omni-present problems. Creating a GUI and your other examples are not omni-present problems. When does a module qualify as a standard module for you?

ihb

See perltoc if you don't know which perldoc to read!


Comment on Re^3: The Bad, the Ugly, and the Good of autovivification
Re^4: The Bad, the Ugly, and the Good of autovivification
by Anonymous Monk on Apr 12, 2005 at 09:53 UTC
    When a module become standard, that attitude changes somewhat.
    But that's a really bad reason to make something part of the standard distribution. Then you'd put thousands of tiny little module into the standard distribution.
    When does a module qualify as a standard module for you?
    IMO, the only modules that should be part of the standard distributions are modules that:
    • Have a tight integration with the perl core. (strict, IO::*, Unicode stuff, B::*, etc).
    • Are necessary (or useful) to download and install other modules (CPAN, ExtUtils::*, etc).
    • Anything that's needed to make Perl "Perl": Exporter, Carp, English, etc.
    So, IMO, many modules already part of the core shouldn't be there: Benchmark, Getopt, Memoize, Switch, etc. Anything that lives, or can live, independently on CPAN doesn't need to be in the main Perl distribution.

    Note that I'm not advocating to remove any module from the core. I'm only saying that mistakes from the past shouldn't be repeated.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (11)
As of 2014-10-31 21:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (224 votes), past polls