simple modules: module managment vs. configuration management

Allen Wirfs-Brock Allen.Wirfs-Brock at
Wed Feb 3 14:59:02 PST 2010

> -----Original Message-----
> From: ihab.awad at [mailto:ihab.awad at]
> Sent: Wednesday, February 03, 2010 12:52 PM
> 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.
It's hard to disagree in the abstract, but that does not mean that the specific form of identification ("name") that appears in a module declaration needs to scale to have meaning that unambiguously  spans the entire web. You have to look at the specific usage of the name.  In this case it is to form associations between imports and exports that are combined within a single "container" (avoiding the tainted word "context"). As the modules declarations that assign the names may be independently authored, it is import to support conventions that have a low risk of unintended name conflict.  It is generally undesirable to associated additional semantics to these name so any proposal to do so should be very carefully examined. 

> ... Java... 
I'm relatively familiar, with Java naming, OSGi, and classloaders, etc...

It is important not to conflate the identity of runtime entities described by source code declaration with the actual source code declaration itself or with the source code based name of the entity.  Arguably, much of the complexity of Java compiling and loading arises from such issues and is also related to the need for Java to maintain the static invariants of the Java type systems.

Because ECMAScript is a dynamically typed language, we avoid the static type system issues and we should also try hard to avoid the conflating names and identity.

> 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 simple module system being proposed imposes very few static invariants.  That makes it easy for component and/or configuration management systems to do their stuff including layering on addition compositional constraints and invariants. By keeping language constructs simple we empower higher level tool makers.

> > 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.
Kris' issue is only a problem if semantics is associated with placement in a namespace.

I intentionally didn't try to define the semantics of "module name space" as I didn't think it was necessary in the context of the statement. However, here are the characteristics that it should have:
1) Flat - there is no semantic hierarchy associated with names
2) Identifier based names, not string literals
3) Associated with a top-level/"global context"/"primordial world" or whatever you want to call that concept.

I support using dotted identifier sequences as names as long as no additional semantics is assigned to the sequence structure.

> 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.

There needs to be some way to identify individual modules, particularly when multiple module declarations are contained in a single "file".

At the language level there has to be a mechanism to "name" modules that is independent of any specific external storage mechanism.

The language should impose no requirement that a module name must match a file name.  

Keep simple things simple, assigning a name to a module definition will be simple and natural for the majority of ECMAScript programmers.  Decoupled naming won't be. 

Things that are separate tend to get lost...

I would argue that the success of the web relative to other hypermedia systems was in part due to the fact that it is composed of "files" with little or no intrinsic semantics rather than a richer *object* system.

> 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".

"Application" is just a word.  Simple modules are trying to provide an organization structure for what could be represented as a single source file.  We should first solve that problem and then built upon it for other forms of containerization/isolation/componentization/etc.

> 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.
Can only digest a limited number of proposal at one time. My general feeling is that we should focus on things that can only be dealt with at a language semantics level language and leave the rest to hosts and tools.  Simple modules have a place within the language because they have a direct effect upon the semantics of identifier resolution.  If packaging/code distribution doesn't impact the language at that level (and I hope it doesn't) then it probably doesn't need to be part of the language definition.


More information about the es-discuss mailing list