Browse thread
Wanted: your feedback on the hierarchy of OCaml Batteries Included
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2008-11-18 (12:22) |
From: | Richard Jones <rich@a...> |
Subject: | Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included |
On Tue, Nov 18, 2008 at 12:17:28PM +0100, David Teller wrote: > This raises two questions: > 1) how important is it to allow third-party modules to extend the > namespace? > 2) how important is it to offer a uniform package structure (where > levels are always separated by '.' rather than some level by '.' and > some by '_')? > > For the moment, we have considered point 1 not very important and point > 2 a little more. There are several reasons to disregard point 1. Among > these, clarity of origin (as in "is this module endorsed by Batteries or > not?") and documentation issues (as in "gosh, this module pretends to be > part of [Data] but I can't find the documentation anywhere in the > documentation of Batteries, wtf?"). > > Do you believe that we should have chosen otherwise? Easy - look at CPAN[1]. If you want to scale a project you have to make decisions that allow a distributed network of people to cooperate, without needing too much central coordination. CPAN is a great example of this loose coupling because packages make their own decision about naming (albeit they can become "official" later - but they won't need to rename unless there is an actual naming conflict). If the problem is documentation or provenance of packages, then add a mechanism to solve that problem. Perl also solves this through an existing, lightweight, distributed mechanism (a standard location to install man-pages, and a standard man-page format and man-page generating mechanism -- POD). Rich. [1] http://www.cpan.org/ -- Richard Jones Red Hat