simple modules

Kevin Curtis kevinc1846 at googlemail.com
Mon Feb 1 17:28:12 PST 2010


On Mon, Feb 1, 2010 at 11:13 PM, David Herman <dherman at mozilla.com> wrote:

> In terms of mechanism, that's not exactly what I had in mind, but in terms
> of purpose that's the rough idea (specifically: "contexts are the means by
> which access to platform resources are mediated" -- yes). Creating new
> contexts would make it possible to restrict what modules can be imported, so
> you could create "pure" execution contexts in which you could evaluate code
> that would not have access to anything with interesting authority. This
> would of course be host-dependent.
>
> Dave
>
>
Understood. Just a final point - modules that are imported with 'import' can
be native modules? That is modules that are implemented in C++.

// compiler tries each in order
import ['JSON', 'http://json.org/modules/json2.js'] as JSON;

In the above case 'JSON' is a native module implemented in C++. If it
doesn't exist a pure ES solution is used. From the end user point of view it
is no matter if a module is implemented natively or via pure ES.
And it is possible, to configure a new context which will deny access to the
native JSON module to code and imported modules within this context - if the
developer desires.

Also, a general point. There has been discussion re ArrayBuffers. Would
'native modules' be a way to present this functionality to ECMAScript. As an
alternative to putting them in the global object/namespace.

import ModArrayBuffer; // imports ArrayBuffer, Int32Array, Int16Array etc

buf = new ArrayBuffer(100);  // create 100-byte ArrayBuffer
var ints = new Int32Array(buf);  // view that buffer as 32-bit integers
var fourShorts = new Int16Array(buf, 20, 4);  // Starting at byte 20 in the
buffer, create a 16-bit

// end
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100202/9fa9dbbc/attachment.html>


More information about the es-discuss mailing list