Beefy Boxes and Bandwidth Generously Provided by pair Networks Cowboy Neal with Hat
Syntactic Confectionery Delight
 
PerlMonks  

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

by Anonymous Monk
on Apr 11, 2005 at 09:15 UTC ( #446537=note: print w/ replies, xml ) Need Help??


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

How about making Hash::NoVivify or some equivalent module a standard module so people don't have to reinvent this tiny wheel all the time?

Presumably, you mean with "standard module", a module that is distributed with the main Perl distribution. However, we already have a (succesful) mechanism in place to prevent reinventing wheels. And it even works without having to upgrade your perl. It's called CPAN.

People don't have to reinvent the wheels to get a graphical environment, to fetch documents with HTTP, or to connect to a database, yet there are no "standard modules" to do any of this.


Comment on Re^2: The Bad, the Ugly, and the Good of autovivification
Re^3: The Bad, the Ugly, and the Good of autovivification
by ihb (Deacon) on Apr 11, 2005 at 16:47 UTC

    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!

      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://446537]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (9)
As of 2014-04-18 11:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (466 votes), past polls