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

[ihb]

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

[Anonymous Monk]

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.