simple modules

[David Herman]

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-bounces at mozilla.org [mailto:es-discuss-bounces at 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 <dherman at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> -- 
> Text by me above is hereby placed in the public domain
> 
>    Cheers,
>    --MarkM
> 
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100203/cc18667d/attachment-0001.html>