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