> -----Original Message-----
> From: ihab.a...@gmail.com [mailto:ihab.a...@gmail.com]
> 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.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
