Re: Proposal: Module name space layout

[Dirk Herrmann]

On Fri, 16 Mar 2001, Martin Grabmueller wrote:

> Please comment on this draft, and feel free to fill in pieces which
> are to terse or incomplete, in your opinion.

First, thanks for providing this proposal.  I assume that we will get a
lot of discussion about different alternatives.  It would be kind if you
could keep track of the different suggestions and maybe incorporate new
ideas into the proposal.  Then, we would end with a very good starting
point for the actual separation into modules.

> ** What do we have now?
> 
> The module (oop goops) contains all functionality needed for
> object-oriented programming with Guile (with a few exceptions in the
> evaluator, which is clearly needed for performance).

Hmmm, just to avoid confusion:  (oop goops) should actually only contain
functionality for object-oriented programming with goops.  Other systems
for object oriented programming should go into (oop <whatever>).

> * Module naming
> 
> Provided we choose to take the `group by functionality' approach, I
> propose the following naming hierarchy (some of them were actually
> suggested by Mikael Djurfeldt).
>
> - Schame language related in     (scheme)
> - Object oriented programming in (oop)
> - Systems programming in         (system)
> - Database programming in        (database)
> - Text processing in             (text)
> - Math/numeric programming in    (math)
> - Network programming in         (network)
> - Graphics programming in        (graphics)
> - GTK+ programming in            (gtk)
> - X programming in               (xlib)
> - Games in                       (games)

I'd like to add:
  - Functions required by guile    (core)

This is for stuff that is necessary to get guile running, but which does
not fit nicely into other categories.  On the other hand, maybe we
actually manage to split boot-9 cleanly into modules - then something like
(core) might not be necessary.

Further, I'd prefer:
  - GUI programming                (gui)
  - GTK+ programming in            (gui gtk)
  - TK programming in              (gui tk)

Alternatively, the hierarchy could start with (ui), i. e. not necessarily
_graphical_ user interfaces:
  - UI programming                 (ui)
  - GTK+ programming in            (ui gtk)
  - TK programming in              (ui tk)

I don't think it we have to expect confusion by putting all UI stuff,
graphical or not, into the same hierarchy.

Best regards,
Dirk Herrmann