On Wed, Feb 3, 2010 at 9:17 PM, Allen Wirfs-Brock <allen.wirfs-br...@microsoft.com> wrote: > 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.
Rather than adding a new term, it might be easier to just stick with Program from ES3/5. A Program would consist of some ES5-style code, and some modules. > 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. I think trying to name all of these conceptual entities just makes things more confusing. Here are the things that I think need discussion and names: Module: the syntactic entity Module name/identifier: how a Program refers to a particular module that it wants to import Module Name Manager/Context/Module Loader: An entity that specifies how to find modules, given their names or identifiers. By creating these, programmers can manage what modules can be seen by what code. I think this (or the next item) is what Kris called a Context in his presentation at the face to face meeting. Global state/??: Something that contains a global object, a set of primordials, a bunch of executable code, and a module name manager. This is I think what you're calling a Subprogram. Note - global state is a terrible term, I'm just using it to have some name for the concept here. Then there are a bunch of interesting questions to ask about the relationship between all of these entities. 1. How is the mapping of what modules go with which names specified? 2. Do we identify the global state with the name manager? 3. Are primordials shared between different global states? Can they be? If they are, are they mutable (creating a channel of communication)? 4. Can values be communicated between different global states? I'm sure there are lots more questions here, which is why we really need to write something up and have something concrete to talk about. -- sam th sa...@ccs.neu.edu _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
