|
in reply to Why Perl does not support database access through core modules?
Let's address the points one-by-one.
Database access is almost a must today
Is it? I beg to differ. For many jobs, database access
is irrelevant. One of the areas Perl has been been used
a lot, even before the web was something more than a handful
of people cared about, is system administration. There, the
typical job does *not* involve access to databases that are
more sophisticated than flat ASCII files.
Besides, when the time comes that "databases access is a must", it'll be integrated in the OS. ;-).
Perl is a high level language
Not more than C, C ++, Pascal, LISP, or ALGOL. And they do
fine without database support in their "core".
We have great modules like DBI and DBD.
Yes, and? There are more great modules on CPAN. They aren't
included in the core either.
"Greatness" or "usefulness" is not a sufficient criterium for a module to be put in the core.
The more modules you put in the core, the harder it is
to maintain the core, and the slower perl development goes.
The perl core is already bloated with modules that do not
have a place in the core - and that should not be taken as
a reason to bloat it even more. IMO (and others shared that
as well), modules should only be put in the core if they
fit one or more of the following criteriums:
- They are tighted to the core, or a core feature, and
are hence often version specific (for instance B::*, pragmes, IO::*).
- They are needed to build, test or install Perl (for
instance, Test::*, ExtUtils::*).
- They are needed to fetch, build, test, or install external
modules (for instance CPAN, MakeMaker, AutoLoader, SelfLoader).
The rest of the modules does not belong in the core.
They are not needed.
Abigail |
Re: Re: Why Perl does not support database access through core modules?
by dragonchild (Archbishop) on Jan 21, 2004 at 13:23 UTC
|
To paraphrase, you would support dropping about half the modules in the core in 5.10 (or .12 or whatever). That list of modules would probably include (if I'm reading you right):
- The CGI::, HTML::, LWP::, Net::, URI::, and HTTP:: namespaces
- The Class:: namespace
- The File:: and IPC:: namespaces (including File::Spec and File::Basename)
- List::Util and Scalar::Util
- The Math:: namespace
- The Memoize:: namespace
- All the DBMs and DB_File
- Search::Dict
- The Text:: namespace
- The Win32 module
- WWW::RobotsRules (and friends)
I'm in complete agreement with your three criteria, but I don't think most people involved in this debate realize not only what's in the core, but also what they would consider to be "core".
------
We are the carpenters and bricklayers of the Information Age.
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
| [reply] |
|
|
Well, I don't support removing anything out of the core,
for reasons of backwards compatibility. But, yes, for most
of modules you list, I agree they should never have been
in the core.
As for your list, not all the modules you mention are part
of the core. LWP for instance is not part of the core - but
that's one module I think should belong in the core, if only
for the fact it's CPAN.pm's preference. For the same reason,
I don't object against the presence of Net::* (which, BTW,
is only a recent addition to the core). CGI::* and HTML::*
don't belong in the core IMO. Neither do URI::* or HTTP::*,
unless LWP would depend on them (if LWP would be in the core).
The Class::* modules shouldn't be in the core. They don't
fit any criteria I mentioned above. OTOH, modules like
File::Spec and File::Basename, and probably more of the File::* modules are used when installing perl and modules.
IPC:: can stay as well, as it's tied to core features.
I consider List::Util and Scalar::Util to be borderline cases. They are heavily tied to perl internals, and could
be quite version dependent. OTOH, the same argument could
be made for several Devel:: modules, and they live happily
on CPAN as well.
Math:: has no reason to be in the core (other than historical reasons). It lives independently on CPAN as well.
Same with Memoize.
DBMs and DB_Files have a long history. DBM support dates
from before perl5, and perl5 still supports 'dbmopen' and
friends as core features.
Search::Dict doesn't belong in the core, IMO. Text::* modules only for where they are needed to support the
POD tools.
The Win32 module isn't part of the Perl core (it says so in
the POD). I wouldn't put the POD in the Perl core either.
WWW::RobotsRules isn't in the core either.
but also what they would consider to be "core".
I think this discussion is only relevant if we consider
the "core" to be what's distributed in the perl-$VERSION.tar.gz file. That is, the file that's made
public by one of the current pumpkings.
Abigail
| [reply] |
|
|
I got my list of what's in the core from http://www.perldoc.com/perl5.8.0/lib.html, which, to me, implies what's supposed to be in the core for 5.8.x. I checked my copy of 5.8.2 and it includes files not on that list (as well as not having files on that list). Files not on that list that I wouldn't think should be in the core include:
- Filter::Simple (is it used by other core modules?)
- Hash::Util (same criteria as Scalar::Util and List::Util)
- Storable and FileCache
- Getopt:: (Is it used by some Makefile.PL's?)
- MIME::
- Digest::MD5 (unless it's needed by CPAN)
- Data::Dumper (this is borderline, IMHO)
- User::
The dbmopen support in perl5 ... Personally, I think that dbmopen and friends should be treated as locked is with Threads. If you use the module, you get the keyword, otherwise it's not reserved. I think that would be an acceptable compromise, but, then again, I've never used (or seen used) dbmopen and friends in my experience.
I would suggest an additional cleanup activity - removal of all reserved words that require an additional module to work. locked() isn't a reserved word in the core ...
------
We are the carpenters and bricklayers of the Information Age.
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
| [reply] |
|
|
|
|
I think that Scalar::Util should be in core, because of the weak references. It would be strange if the perl binary could handle weakrefs but you would have to download a module to use them. AFAIK, weak refs were experimental with 5.6 versions, but they are not in 5.8, and so 5.8 has Scalar::Util in core, 5.6 does not. Correct me if I'm wrong please.
| [reply] |
|
|
|
|
| |
|
There are no HTML or HTTP modules in core.
| [reply] |
Re: Re: Why Perl does not support database access through core modules?
by hardburn (Abbot) on Jan 21, 2004 at 14:42 UTC
|
when the time comes that "databases access is a must", it'll be integrated in the OS
Depending on your definition of "integrated", they practically already are. ReiserFS 4 implements many features found in a DBMS (it probably has better transaction support than MySQL). I doubt we'll see a really sophisticated DBMS in any kernel, but even existing database systems work at a fairly low-level.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l] |
|
|
