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.ko...@cixar.com> To: David Herman <dher...@mozilla.com> Cc: es-discuss Steen <es-discuss@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 <dher...@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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
