simple modules

[Kevin Curtis]

Suppose - maybe unlikely - the client platform webcam is exposed to
ECMAScript in a HTML5 webapp. How would this be accessed in a module system:

import modwebcam; // what is this? native code? do i have access to it? via
a container/context/global object?
import JSON; // is this native code?

How modules, contexts (global objects) and powerful platform
resources/objects/capabilities interact is interesting. At the moment
platform objects are placed in the global object. In Ihab's proposal access
to platform objects are parcelled out via 'parametized modules'. Modules are
explicity passed resources at instantiation (i think).

Two type of module: impure modules, which access platform modules (eg xhr,
dom, webcam) VS pure modules (in memory calculations).

On Mon, Feb 1, 2010 at 5:21 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>wrote:

> On Mon, Feb 1, 2010 at 1:04 AM, <ihab.awad at gmail.com> wrote:
> >
> > Hi Sam,
> >
> > On Sun, Jan 31, 2010 at 6:56 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>
> wrote:
> > > First, it's also possible to achieve isolation via lexical scope by
> > > using functions, closures, and objects, as Dave's example shows.  Our
> > > proposal attempts to leverage the existing facilities in EcmaScript to
> > > achieve most of isolation, using modules for name management and
> > > restricting the top-level lexical environment.
> >
> > But, in some module M that imports X, Y and Z, the top-level lexical
> > environment *must* include access to all the state encapsulated by X,
> > Y and Z.
>
> That's only the case if X, Y, and Z provide access to their internal
> state via the bindings they export.  For example:
>
> module MemoFun {
>  var table = {};
>  export function f(x) {
>    if table[x] { return table[x]; }
>    // imagine complex but pure computation here
>    var tmp = x + 7;
>    table[x] = tmp;
>    return tmp;
>   }
> }
>
> Here, the only access provided to the state is via the function `f'.
> Outside modules cannot disturb the invariants of the code at all.
>
> > > Second, we expect that needing to isolate untrusted code is the
> > > uncommon case for importing a module.
> >
> > That is only true if you *completely* trust all the code you and all
> > your coworkers write on a large project. Otherwise, the issue is not
> > isolating untrusted *code* but isolating the extent of authorities
> > into code. This is important for both security and software
> > engineering.
>
> It has been my experience that most of the isolation needed between
> modules can be accomplished by lexical scope.  For example, in the
> MemoFun module, the function `f' doesn't have to trust any other
> modules that it might import (or that might import it) to avoid
> interference with its invariants - lexical scope takes care of that.
>
>
> > > So, the way I think of it, everything in our proposal is internally
> > > linked, except insofar as a Context might specify a different behavior
> > > for the name of some module.
> >
> > So you propose linking to a standard library using some agreed-upon
> > name. Let's say it's "stdlib". So, when I say:
> >
> >  import stdlib;
> >  /* ... my code here ... */
> >
> > If "stdlib" were some reference to some code which I could make more
> > or less independently of the container (perhaps subject to its
> > permission, but not too much else), then this is internal linking.
> > However, if "stdlib" is not only some code but an object *with
> > expected powers* that the container must be expected to set up for me
> > ahead of time, that sounds like external linking.
> >
> > Am I incorrect in my use of the terms?
>
> I would normally say that a module that imports the standard library
> in that fashion is internally linked.  To take a different language,
> import in Java is internal linking, even though the meaning of names
> can be rearranged via the classpath (or via the filesystem).  But
> given that we always have the power to change the environment the
> program operates in, the boundary between internal and external
> linking can become fuzzy.
>
> > In any case, my point stands. The namespaces for "pure code being
> > brought in" and "powers granted to me by my container" are being
> > conflated. For the former, you need modules. For the latter, you need
> > some sort of "service registry" or whatever else.
>
> I think that in many cases, conflating these two concepts is
> appropriate.  For example, if I import jQuery to add some simple bit
> of functionality to my homepage, I almost certainly want to give it
> access to all of the things I have access to.  This is the common case
> that our strawman tries to make simple.  However, in other contexts a
> service registry may be more appropriate, and that can be built on top
> of modules, using either the dynamic loading features, or simple
> lexical scope with functions and objects.
>
> --
> sam th
> samth at ccs.neu.edu
> _______________________________________________
> 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/20100201/d418a204/attachment.html>