develooper Front page | perl.perl6.stdlib | Postings from September 2000

Re: RFC 260 (v1) More modules

Thread Previous | Thread Next
From:
Andy Dougherty
Date:
September 21, 2000 08:33
Subject:
Re: RFC 260 (v1) More modules
Message ID:
Pine.SOL.4.10.10009210909260.6733-100000@maxwell.phys.lafayette.edu
On Thu, 21 Sep 2000, Michael G Schwern wrote:

> Sounds like a seperate RFC.  Like I said, I want to reverse some of
> the philosophies that have kept things like LWP out of the core for so
> long.

The differing timescales of development by the myriad different authors
involved has always been one of the biggest obstacles.  We've averaged
approximately one major release per year for the past 6 years.  Getting
everbody in sync for that one release is likely to be pretty hard.

In the early days of 5.00*, most modules were evolving far too rapidly to
try to freeze and incorporate into the main distribution.  A lot of them
were too non-portable too and didn't necessarily work in a lot of places
where perl did.  More recently, in the 5.005 - 5.6.0 era, many modules
have stabilized and the synchronization problem is somewhat smaller.

Whether or not the early days of perl6.0.x will again be times of rapid
module evolution (in which case freezing too many of them to ship with
6.0.0 might be a mistake) is not obvious to me at this point.

This is not to argue either for or against "more modules", nor to argue
that the perl5 distributions have been perfect.  But I do wish to
emphasize that many (but not necessarily all) of "the philosophies that
have kept things ... out of the core for so long" are actually reasonable
philosophies that I hope are continued under perl6.

Specifically, I think a necessary (but not necessarily sufficient) set of
criteria ought to include at least the following:

1.  The module is stable.  That is, during the lifetime of the relevant
perl release (e.g. 1 year in the perl5 universe) no major changes are
expected.  (Maintenance fixes on the perl6.even.x time-scale are of
course, ok.)

2.  The module works (or at least passes its own regression tests) on most
(if not all) of the platforms that perl supports.  (Note that "work" may
simply mean "fail gracefully" in some circumstances.  I wouldn't really
expect System V IPC to work on the Palm Pilot, for example.)

3.  The module is likely to be sufficiently useful to a sufficiently broad
set of perl users that inclusion in the main distribution is worth the
effort involved.  (As a corollary, the larger and the more complex the
module, the higher this hurdle ought to be.  A module that would double
the size of the perl .tar.gz distribution had better be very useful
indeed.)

4.  The module is of sufficiently high quality.

5.  The module author agrees.


During my time as pumpkin holder, nearly all modules proposed for
inclusion quickly fell over under either 1, 2, or 5.

I suspect that some that have fallen afoul of numbers 2 or 3 might not
have done so had a champion stepped forward and said (in effect) "I want
this in the core and I will personally take care of whatever patching and
support is needed to make it so."

Items 3 and 4, of course, call for more difficult judgments, and this RFC
is a good start towards spelling them out more carefully.  That is a quite
welcome development.  You might also want to comment explicitly on the
SDK and the balance between more modules in the standard library and
more effort on developing an SDK.  Then again, you might not prefer to go
there :-).

-- 
    Andy Dougherty		doughera@lafayette.edu
    Dept. of Physics
    Lafayette College, Easton PA 18042




Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About