Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

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

by ihb (Deacon)
on Apr 10, 2005 at 18:11 UTC ( [id://446438]=note: print w/replies, xml ) Need Help??


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

Yeah, I think a lot of people get bitten by that and I certainly did when I was new. This isn't a recent issue and Brent gave us Hash::NoVivify five year ago. Still, I see no one using it. 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?

ihb

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

Replies are listed 'Best First'.
Re^2: The Bad, the Ugly, and the Good of autovivification
by Anonymous Monk on Apr 11, 2005 at 09:15 UTC
    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.

      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
Domain Nodelet?
Node Status?
node history
Node Type: note [id://446438]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (4)
As of 2024-03-29 08:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found