simple modules

[Kam Kasravi]

I thought I would also mention that contexts (as in execution context), sandbox, 
security and other terms are also heavily used in html5. Defining a module framework 
without at least being familiar with current and upcoming browser environments 
may result in an implementation that is at odds with html5 entities which use 
similar terminology. For example, a SecureESContext would probably prevent 
cross-document messaging, channel messaging and other mechanisms that exist or 
are being defined in html5. Strictly speaking cross-document messaging violates 
TCB since existence of adjacent iframes and their source domains can be determined.  
Yes I'm not sure current module strawmen define a general mechanism where 
module-to-module communication can occur.

Perhaps to complement the discussion, there is a variety of literature which describes modules 
in different ways. Given one goal of harmony is to make programming in the large 
easier, I would think a module framework's first goal is to make it easier to organize code.

Some papers on modules with a few choice quotes.

Functions, Frames and Interactions. Claus Reinke.
  'A module is a ... collection ... of elements. It provides a separate namespace with explicit control of import/export.'

Modular Object-Oriented Programming with Units and Mixins. Findler, Flatt
  'A module delineates boundaries for separate development...'

Metalevel Building Blocks for Modular Systems. Jagannathan
  'allow ... module elaboration with minimal program rewriting...'

The Influence of Software Module Systems on Modular Verification. Li, Fisler, Krishnamurthi.
  'feature-oriented modules ... simplify key software engineering problems such as configurability, maintainability, and evolution.'


kam






________________________________
From: Kris Kowal <kris.kowal at cixar.com>
To: David Herman <dherman at mozilla.com>
Cc: es-discuss Steen <es-discuss at mozilla.org>
Sent: Tue, February 2, 2010 6:23:55 PM
Subject: Re: simple modules

On Tue, Feb 2, 2010 at 5:27 PM, David Herman <dherman at mozilla.com> wrote:
> On Feb 2, 2010, at 5:03 PM, Kris Kowal wrote:
>> Presuming that in the proverbial glossary a "Context" is what ES
>> presently calls an execution context that has some intrinsic
>> "Primordials", and a "Sandbox" is a mapping from unique module
>> identifiers to modules (albeit instances or makers depending on what
>> proposal you're talking about), does this proposal suggest that there
>> is exactly one "Context" for every "Sandbox" and that any "module
>> block statement" evaluated in a context populates the corresponding
>> sandbox with a mapping from the given module identifier to the first
>> class exports object of that module?

> Not quite sure how to unpack the question. Let me try a quick sketch, at least for the simple modules system:
>
> - a "module ID resolver" is a mapping from module ID's to module instances
> - a "module context" is a set of module instances

Please call this something else.  It is confusing for "context" to
mean "execution context" and "module context" depending on the
"context".  I've called this a "system of modules" or "sandbox of
modules" in the past.

> Different module contexts may have different module ID resolvers, so for example it would be possible for host environments to provide a SecureESContext that didn't allow identifiers to resolve to the "filesystem" module or the "dom" module.

This verbiage implies black-listing.  It would be good to be clear
that the object formerly known as a "module context" should be
explicitly populated with a white-list of module instances for SES.

> There would be an API for dynamically evaluating code in a given context; roughly a `loadModule' that takes a Context argument (or is a method of Context).

Tell me more about this "loadModule" and how it works.  I am concerned
that modules would be "autonomous"; I firmly believe that a chunk of
code should never select its own name, or more to the point, it should
never be necessary to edit code to give a module, or a tree of
modules, an alternate name.  That kind of coupling has wasted many
days of my time, integrating disparate projects with tight linkage.

Kris Kowal

P.S., for some liesure reading, here is the Narwhal CommonJS "module
context" implementation:
http://github.com/280north/narwhal/blob/master/lib/sandbox.js
http://github.com/280north/narwhal/blob/master/lib/loader.js
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100203/654c707c/attachment-0001.html>