module naming

[Neil W. Van Dyke]

I'm writing a bunch of general-purpose Guile modules right now, and
noticed a little awkwardness with some of the module naming...

(You'll pardon me for stating some obvious things below in an attempt to
communicate my current understanding and opinions.)

Application areas tend to evolve over time, and I wonder if a
functionality-based taxonomy of modules is the best way to name modules.

Certainly, "functionality" is one excellent way to organize descriptions
of modules on a Web site that offers a human-browsable catalog of Guile
modules.  In this directory, a given module would probably appear in
multiple functional categories.  Detaching the module name from
"functionality" taxonomies might avoid a cumbersome mess later.

For example, circa 1994, Web-related modules might've been categorized
somewhere under both "Networking" and "Text : Hypertext".  A few years
later, as the Web became more central an idea, and more ideas were built
upon it and resulted in additional modules, our human-browsable catalog
might've put "Web" as a category on their first page.  The functionality
of our 1994-era HTTP-downloading module probably didn't change, so its
module name remains the same and code remains unbroken, even though we'd
adapted our human-browsable catalogs to help people find that module.

As Martin Grabmueller noted in "module-layout.text" 1.1, it's difficult
to anticipate how taxonomies of functionality will evolve in the future.

Rather than trying to come up with a long-lived functional taxonomy for
the canonical names of modules, it might be more useful to employ more
of a flat namespace for modules.

Levels of hierarchy might then be used more for purposes such as
representing aggregation hierarchies of components in frameworks.  For
example, a module representing buttons in GTK+ doesn't make sense
outside of the GTK+ framework, and GTK+ is a collection of modules
distributed as a coherent whole.  So the module name `(gtk button)'
reflects that architectural hierarchy, while also avoiding needless
clutter of the top-level namespace with names such as `(gtk-button)'.

Under this suggested module naming convention, the module currently
named `(oop goops)', for example, might instead be named `(goops)' --
*unless* there were some architectural pieces common to all things that
could be called `(oop ...)'.  Or perhaps unless there were some
fundamental mutual exclusion between all things called `(oop <name>)',
such as they all used Guile primitive data-rep features that could only
support one object system per interpreter.

Individual development teams would be free to pick a top-level name for
their grand projects (e.g., `(apache)', had Apache been implemented in
Guile instead of C), and build beneath it whatever hierarchical
structure makes sense.

One tangential suggestion, which should be controversial: We *might*
also socially consider that hypothetical Apache team to have "ownership"
of the `(apache)' namespace, such that it would be understood that other
people probably shouldn't be naming modules `(apache ...)' without
approval from the team, unless the team already gave blanket approval
for anyone to add modules into that namespace.  This particular social
guideline is not the same thing as trademark recognition, since this
guideline pertains to a third party wanting to name a module `(apache
foo)' but not to the same party wanting to name a top-level module
`(apache-foo)'.

Comments welcome.

Neil V. (nwv)

-- 
                                          Neil W. Van Dyke <address@hidden>
                                          http://www.neilvandyke.org/