Re: Perl 6 modules plan

Front page | perl.perl6.stdlib | Postings from August 2001

Thread Previous | Thread Next

From:

John Siracusa

Date:

August 24, 2001 20:52

Subject:

Re: Perl 6 modules plan

Message ID:

B7AC9948.1E8B7%siracusa@mindspring.com

I just subscribed, so forgive me if this has been covered before (I haven't
read all of the archives yet)

STYLE:

> There should be tools, guidelines and processes to assist authors in writing
> quality modules.  See also perl-qa@perl.org.

> Specifically:
> Style guide
> Naming guidelines

I know this is mostly referring to entire modules, but I'd like to see some
guidelines in the area of APIs, from method naming conventions all the way
up to some "best practices" on the APIs themselves.  Perl 5 modules are all
over the place in terms of naming: MyFunc(), myMethod(), my_method(),
get_value(), Value(), LoadValue(), setValue(), etc. etc.

If you ask any Java programmer which is "correct", myJavaMethod() or
My_Java_Method(), I think you'll get a straight answer.  Same deal with C or
even C++, for the most part.  Ask a Perl programmer and you'll likely span
the entire range of possibly API styles and philosophies.

We need to make some decisions.  But no B&D "rules" here, just "guidelines."

VERSIONING:

I mentioned this on another list, and I thought I'd bring it up here as
well.  I think NeXT-style "bundles" offer an interesting solution for
keeping several versions of a single library installed at the same time,
with well-defined major/minor version compatibility rules.  This
functionality becomes even more important with the proposed ability to
specify modules by version (or version range, etc.)  More information on
bundles is available at Apple's web site.  I think there are some ideas
worth stealing here:

http://gemma.apple.com/techpubs/macosx/Essentials/SystemOverview/Bundles/

HIERARCHY:

As was pointed out earlier, we do need a real, planned hierarchy to avoid
Time/Date and WWW/Web/HTML/CGI-type messes.  Standards, standards,
standards!  (Easy for me to type, I know... ;)

I'll also put in my vote for "deep" hierarchies.  No, not:

    Universe::SolarSystem::Earth::NorthAmerica::US::MA::Newton::Person

But two, three, or even four levels is not too severe, IMO, and will be
necessary in the long run anyway.  Individual "module distributions" can
retain "shorter" names, but the individual modules that make up a
distribution should be named without too much worry about namespace depth.
To use the previously maligned Net:: prefix as an example, I really don't
think this is all that bad:

    cpan> install Net::HTTP

    installing Net::HTTP::Message
    installing Net::HTTP::Request
    installing Net::HTTP::Response
    installing Net::HTTP::Headers
    installing Net::HTTP::Cookie
    installing Net::HTTP::UserAgent
    installing Net::HTTP::UserAgent::Robot
    ...

Okay, so maybe we all decide that HTTP is such an important protocol that it
should be pushed up as HTTP::*, or maybe even, oh, I dunno, LWP::* (that
makes sense to everyone, right? ;)

Mark my words: any "convenient" flattening will come back to haunt us later
in the game, as I think the Perl 5 CPAN experience has taught us to some
degree (witness IO::*).  No one wants to type a million "::"s, but at some
point the community has to decide: are we making a bunch of neat/useful
modules as a hobby, or are we actually trying to build a standardized,
logical, robust, self-consistent framework of code that spans the entire
range of possible applications?

---

I think that's it for now...more to come, I'm sure :)

-John

Thread Previous | Thread Next