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.
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss