Front page | perl.perl6.stdlib |
Postings from June 2002
Re: More 6PAN musings: local namespaces
From: Luke Palmer
June 17, 2002 13:12
Re: More 6PAN musings: local namespaces
Message ID: Pine.LNX.email@example.com
On Sun, 16 Jun 2002, Webb Sprague wrote:
> > This is a
> > solvable problem. We shouldn't just throw up our
> > hands based on past
> > failures.
> I am not a frequent contributor to this list, just a
> Perl programmer who doesn't want to learn Java. :)
Java's hell if you know Perl. You're used to doing things in 200
keystrokes, and suddenly it takes you 5000. "The easy things should be
long, and the hard things should be longer... and slower." (i.e. I don't
> Now that Perl 6 will become truly object-oriented, the
> only reason to use Java (besides Java being the only
> computer language you have ever heard of besides VB)
> is the coherent and excellently designed module system
> that Sun has come up with for it. I think the debates
> about CPAN can be the beginning of a redesign that
> might lead to a new, comparable approach for the Perl
Hopefully. I like comprehensive, well-designed standard libraries.
> So, in order for me to avoid learning Java, I propose
> that a CPAN "Curation Project", or an Extended
> Standard Perl Library", be formed.
Or, Standard Extended Library of Perl. SELP is more pronouncable than
ESPL. SELF is better than ESPN, too.
> First of all, keep CPAN the way it is -- a central
> unstructured location to put modules that the
> community may be interested in. It works fine for
> that currently. However, its unstructured character
> makes it difficult to base business and other
> organizational solutions on it. Furthermore, creating
> an automated system that will magically make it into a
> structured, predictable, coherent library is, I think,
> impossible, no matter how well designed namespaces (or
> whatever other solution) might be.
I like CPAN the way it is too. I reiterate, though, that the heirarchy
structure needs to be more strict and sensible.
> To address the shortcomings of CPAN, then, we add a
> layer of indirection--an "Extended Standard Perl
> Library", an evolving software tree based on modules
> first loaded in CPAN that have been gathered,
> standardized, and tested by a group of Perl hackers.
> This library should be highly managed, by real people,
> in order to give it the coherence and predictability
> that CPAN lacks. The contents of the Extended Perl
> Library should be evaluated not only on their
> usefulness and robustness, but also on their lack of
> duplicated functionality with other modules.
> (Perphaps the "standard" library should be confined to
> duplicating or interfacing the standard C library,
> while extensions to that would be part of the extended
> library.) The old CPAN would still exist and would be
> the first place that a module would be available for
> the community; once the Extended Perl Library hackers
CHELP - Community of Hackers of the Extended Library of Perl. Forgive me,
I'm in an odd mood.
> decided the module is appropriate as a general
> solution, it would be moved into the Extended Library
> Perhaps a pipeline could be CPAN -> Nominated ->
> Unstable -> Testing -> Standard. New versions of an
> already accepted module that don't break interface
> would come in under Unstable. If modules broke
> interface, then they should be put into Nominated.
> Modules that the group has not evaluated would come in
> under CPAN (i.e. "register and upload"). Although some
> module writers may feel this cramps their style, we
> all must sacrifice for the greater good sometimes.
Hmm... I can see a problem with this. First, people's coding styles vary.
One part of the standard library would be
while another part would be
$x->foo = 13;
which isn't right for an (extended) standard library. Maybe I'm being too
strict-minded. After all, it is extended.
Also, there would undoubtedly be redundant code everywhere. There
wouldn't be the elegant interdependance that Java or C++'s standard
libraries have. It'd be more of a tangled interdependance.
See, both Java and C++ (the ones whose standard libraries I like) have
very well-planned libraries. The very nature of CPAN can't do this. Once
you get to know CPAN, it's very nice. You can find anything you want there
and get it working almost all the time. It just needs to be easier to get
to know it.
> The library should adopt tools like Debian's "apt" to
> keep local copies updated automatically, perhaps on
> demand (when you say "use foo", check to make sure
> "foo" is current, download if not, etc).
I like the idea. Can't do it if interface changes, though.
> Such an Extended Library might also be a step toward
> an application server approach (did you catch the plug
> for making all Extended Library objects serializable
> through some inheritance mechanism?).
Apparently there's already big plans for making things serializable in a
> Here is a possible rough roadmap: sift through CPAN
> and come up with a map of the functionality sets of
> modules provide and a map of the modules that provide
> them (e.g.--"parsing HTML" is a function,
> "LWP::whatever" is a module providing that
> functionality). Identify the best modules to provide
> each function. Also identify functionality not
> addressed anywhere in CPAN (probably very little).
Only one I've found is a Telnet Mud Server. Nobody's written a Telnet Mud
Server module!! I was going to, but then I didn't.
> Create a subset of CPAN from the modules selected,
> then evaluate the modules this subset contains for
> interoperability and predictability. This evaluation
> will probably include deciding to delete some
> duplicated functionality from modules or moving
> functionality to more appropriate places; it will also
> include creating consistent naming and parameter
> schemes for maximum predictability and modifying the
> modules to reflect these changes.
Sounds like a maintainance nightmare to me. Who will you find to do such a
> At times it may
> involve merging two or more modules to make a third,
> better, module. Additionally, create new modules that
> address gaps identified earlier. Then package it up,
> test, download. (I make it sound so easy...) I think
> a few central people could do the evaluating and
> mapping of CPAN as a whole, but modifying the modules
> to fit into the new scheme should fall to module
> Of course, the decisions about contents and interfaces
> should be made democratically.
Representitive or direct? :)
> The organization of
> the people who work on this Extended Library could
> probably be based partly on the Debian project,
> essentially performs the same role for a much larger
> set of software (with the important difference that
> Debian offers multiple solutions to the same problem,
> which the Extended Library should avoid). Current
> module maintainers/writers would make excellent
> charter members of the Extended Library organization.
> At all points, Extended Library decisions would be
> made by concensus or vote.
I think it's going a bit too far now. It would require much more
organized work than people would be willing to put into it. CPAN is mostly
a "I wrote it because I wanted it" collection. With an unstructured, and,
well, unpaid community like Perl, this wouldn't work too well.
> So, please respond with your, ahem, responses. I am
> willing to offer any help that I can.
> I am sorry to
> jump to the discussion with such a long rant,
Hey, that's how I did it. Plus, now you've got my counter-rant to make
yours not look so large.
> but I am
> afraid that the solutions to The CPAN Problem have so
> far concentrated on finding automatic solutions (like
> namespaces) to problems which require human
> intervention, planning, and creativity.
Agreed completely. I don't think there's any way to make a system that is
so inherently nifty that we humans don't have to do anything to keep it
that way. And too many people are going for that, IMO.
> With thanks and respect to the Perl Community,
You're welcome ;)