OK, I think I get the concept. I certainly agree that there is a real world need for a unit of isolation for the processing of groups of Applications (in the simple module proposal sense or Programs in the ES3 sense) . Such a unit would presumably represent independent processing of the group of Applications including rejecting conflicting Module declaration, input/export binding, etc.
Here are some things that seem less clear: The semantics of Applications and the combination of applications including name binding are (at ultimately will be) will fully specified. The actual identification and access mechanism of the external containers of the Applications are current outside the scope of the ES specification. In addition, I think there is fairly broad agreement that module identifiers shouldn't embed configuration or container identification information. Given this, is there actually any need for a standard mechanism for dynamic intercessions with the process of populating the unit with Applications? It seems that the only thing that could be done that wouldn't potentially change the fully specified semantics of these language constructs is the handling of the external containers that is something that, so far, has been placed out of scope. There is more involved in these units than just Module binding. There is the "global" object and the primordial bindings to consider. There presumably would be some dynamic communications path or state sharing between units that needs to be established. Possibly other things. Do we really want to treat each of these aspects completely independently? Can we simplify things to a single "unit" concept. Isn't most of what is involved in establishing such one of these isolation units exactly the same as what is involved in establishing the "global" unit? The central concept here doesn't seem to be about "modules". Those are just an organizing concept for ECMAScript source code. It also doesn't seem be about an actor as might be given a action oriented name such as "loader" Instead it seems about something much more existential in nature. These units are things that may come into existence. When they do, they have certain fixed and variable characteristics. So, here is how I might start to organize and name some of these concepts Subprogram: One of the "Units of isolation". Application: The syntactic unit from the modules proposal. (alternatively, consider "Fragment" in place of "Application". As in source code fragment.) Program: A dynamic set of objects that are manipulated by a dynamic set of Subprograms. Every Programs initially has one Subprogrm. A Subprogram integrates a set of Applications, along with, a independent set of primordial objects, and a global object. It includes all the mechanisms necessary to do Module import/export binding and the other normal ECMAScript bindings. Programs initially have one Subprogram. The code of that Subprogram may cause other Subprogram to come into existence and establish any necessary object sharing or other communications channels with them. From: David Herman [mailto:dher...@mozilla.com] Sent: Wednesday, February 03, 2010 5:06 PM To: Allen Wirfs-Brock Cc: Mark Miller; es-discuss Steen Subject: Re: simple modules Sorry for the confusion-- we're discussing a name for something that is not part of the current strawman. One of the things Sam and I were trying to do was separate the concerns of modularity and isolation. So there's a not-fully-worked-out strawman waiting to be written for isolation. That's what we're talking about a name for. The rough idea of the impending strawman is that there would be the ability to create a new ModuleLoader with which one could load modules completely isolated from the current setting. Thus every instance of a module would be tied to a particular loader. Per loader, there would never be more than one instance of a given module, but in an application with multiple loaders, there might be multiple distinct instances of the same module. Sorry to have confused things by discussing a non-existent (yet) proposal. :/ Dave On Feb 3, 2010, at 4:50 PM, Allen Wirfs-Brock wrote: It's still not clear to me what we are trying to name? According to the proposal, a Module is a syntactic element that is part of an Application and Application can consist of multiple Modules. A complete Application is presumably represented by an external container such as a source file so we will presumably "load" Applications, not Modules. (If "load" is even the correct concept, I don't see any reasons you couldn't build a Harmony implementation where you feed a bunch of such Application source containers to an Harmony compiler that generated a self-contained binary exe. Where does the "loading" take place in that scenario?) Are we trying to name the specification mechanism that is used to describe the semantic association between ImportDeclarations and ExportDeclarations or are we trying to name a hypothetical extensible mechanism of a Harmony implementation that is used to identify and located the external containers of Applications, or are we naming a specific semantic abstraction that we intend to reify that permits some sort of dynamic intercessions in the binding of ModuleSpecifiers, or something else? (sorry, if I'm being a pain about this but it is pretty clear that everybody is reading lots of implications into the names that are being thrown around) Allen From: es-discuss-boun...@mozilla.org<mailto:es-discuss-boun...@mozilla.org> [mailto:es-discuss-boun...@mozilla.org] On Behalf Of David Herman Sent: Wednesday, February 03, 2010 4:07 PM To: Mark Miller Cc: es-discuss Steen Subject: Re: simple modules I like it. I might prefer "module loader" for a bit more concreteness. But it has the benefit of concreteness and familiarity. Dave On Feb 3, 2010, at 4:03 PM, Mark Miller wrote: On Wed, Feb 3, 2010 at 3:11 PM, David Herman <dher...@mozilla.com<mailto:dher...@mozilla.com>> wrote: > Well, a "module system" is a language construct that provides modules. I > think "sandbox" sort of suggests more isolation than is necessarily provided. > PLT Scheme uses the worst possible name for the concept (I won't even say > what it is, it's so awful). > > I'll think about alternatives and update the wiki. How about "module group"? Since, AFAICT, the concept being named here, in Java, corresponds to a ClassLoader, I suggest "loader". (E calls these "loaders" as well.) Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org<mailto:es-discuss@mozilla.org> https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
