On Mon, Feb 1, 2010 at 11:13 PM, David Herman <[email protected]> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
