simple modules: module managment vs. configuration management

[ihab.awad at gmail.com]

Hi Allen,

Since this thread was referred to by the "simple modules" thread, here
are some remarks.

On Sat, Jan 30, 2010 at 7:43 PM, Allen Wirfs-Brock
<Allen.Wirfs-Brock at microsoft.com> wrote:
> One of the points that I recall is the importance of not entangling “module
> management” with “configuration management”. ...
> Module management becomes entangled with configuration  management when
> configuration management  information is embedded within the actual module
> definitions. When this occurs, configuration changes require the
> modification of the actual source code of modules.  For example, if a module
> import statement uses a hard-code file path or server name then moving the
> location of an imported module requires modification of every module that
> performs such an import. ...
> The use of a string literal as
> ModuleSpecifiers is an attractive nuisance that makes it too easy to
> entangle module management and configuration management.

I don't have an issue per se with whether module IDs are string
literals or not, but just to guide where this is going, I'd like to
propose a candidate goal: The module naming and identification scheme
should scale to the open Web.

One of the most instructive examples of module naming, imho, is Java;
how it evolved as it grew, and the solutions developed that attempt to
address its shortcomings.

Java classes declare themselves into a global namespace. They do so
using short names, which were okay for casual development. In response
to the problem of packaging, distribution and versioning at scale,
OSGi came along defining "bundles" in which classes live, and bundles
could import Java packages from one another. Crucially, however, it is
still impossible for one bundle to import two different versions of
class com.foo.Utils from two different bundles. This is baked into the
default interaction between Java ClassLoaders and classes. It is not
impossible to fix this, theoretically, but in practice, the
ClassLoader gymnastics required render it pretty much unusable.

OSGi was built to allow modules to be assembled together, and a
mutually acceptable version solution to be computed, at run time
(think: the Eclipse plugin system, which uses OSGi). Apache Maven is a
similar solution to OSGi -- but one that operates at build time. It
has the same properties -- and problems.

> The module name space gets populated in accordance
> with a specified set of semantic rules by processing Module declarations
> contained within Applications.

As Kris Kowal pointed out in a separate thread, this is the first
mistake of Java: that classes have authority over where they are
placed in the namespace. The practicality of your suggestion is
dependent on what you mean by "module name space" and how it is
managed, but the most important point is that the declared name of a
module must not be the [only] way in which it is imported by others.

As for whether modules should declare their own names by which they
are imported *at all*: I am a bit on the fence, but leaning towards
"no". It's a pain to have to write modules and manually try to keep
the file names in sync with the internal module names; it makes
refactoring hard. Of course, "files" and HTTP resources are an
antiquated concept that should be discarded in favor of pure objects,
right? :) But if I were designing a module *object* system, I would
put the name -> module mapping logically outside the module; the
module would be reachable from a dictionary but would not *contain*
its own name in that dictionary.

Another point is that Applications are increasingly obsolete. :) The
Web is made of large numbers of entities collaborating. One of the
important use cases is plugins, gadgets, ... loaded recursively into
other environments. A "guest" module should be able to have *some* say
in how its dependencies are resolved, even if this is subject to the
permission of its "host".

My answer to this is the packages proposal. If you can recast your
comments as a discussion of that, I think it would be helpful.

> Instead, modules might be identified (in both Module declarations and
> ImportDeclarations ) as any of the following alternatives 1) a simple
> identifier, 2) a sequences of dot separated identifiers (my current
> preference), or 3) a sequence of identifiers separated by some other
> delimiter such as “::”.  These identifiers populate a single module name
> space that is distinct from the EnvironmentRecords used for normal
> identifier resolution.

It seems like you want the identifiers to have some internal,
compiler-visible structure. What does that map onto? Just a
convention? Some hierarchy in deployment?

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA