On Jan 18, 2010, at 12:14 PM, Brendan Eich wrote:
> On Jan 18, 2010, at 11:58 AM, Mark S. Miller wrote:
>
>> On Mon, Jan 18, 2010 at 10:25 AM, Brendan Eich <[email protected]> wrote:
>> On Jan 18, 2010, at 10:20 AM, Mark S. Miller wrote:
>>
>>> I simply don't understand what you mean by the phrase "migrate into a
>>> module". What does this mean?
>>
>> Use on the inside of a module. I have code I want to put in a module. It
>> uses Prototype. That's all.
>>
>> How would you express "putting code in a module"? I just don't have a
>> concrete idea what you mean. Could you show a program fragment?
>
> Copy and paste. I copy prototype-1.6.0.2.js into mybigfatmodule.js, add my
> special sauce which makes good use of Prototype's extensions to primordials
> such as Array.prototype, and then purvey it to the world.
>
>
>> Why is this hard to understand? Are you assuming modules are small,
>>
>> Or at least, that module boundaries coincide with boundaries between
>> separately written source files, as is the case with module systems I'm
>> familiar with from other languages. For example, Java classes-as-modules.
>
> Nothing prevents people from inline-expanding Prototype into their code,
> crashing and carrying whatever they want. The codesearch hits I linked
> earlier shows instances, including v8's raytrace.js benchmark.
>
> Would a raytracer with inline-expanded, possibly hand-minimized Prototype
> make a good module? Maybe, maybe not; I'm not judging, just noticing that
> people do this sort of thing today on the Web. Modules might reform all bad
> habits, but probably not -- and developers don't all agree on your definition
> of "bad".
>
>
>> and/or consisting of new code only?
>>
>> Or at least a new revision of old code, in order to repackage the code to do
>> module-based import/export linkage, rather than the current practice of
>> implicit linkage through shared global variables.
>
> Precedent and developer conversations I've had strongly suggest that some
> code wants mutable primordials on the inside of a module that can be consumed
> without the mutations affecting the importer's primordials.
>
>
>> Since I do not yet understand what you are trying to say, I may be the wrong
>> person to guess why I'm finding it hard to understand ;). Altogether, my
>> best guess right now is that what you are calling a module is what I would
>> call a sandbox.
>
> Could be. Is there a hard difference? It's not obvious.
>
> Users definitely want isolated frame-like "modules". Some browsers even
> support such things, with postMessage for safe inter-"module" communication.
> It's a bit heavyweight, but to get back to the topic of this sub-thread: is
> the only alternative frozen primordials? I think not.
I agree with Brendan, we've actually been working on "module"-like behaviour
with iframes in webkit, basically allowing a detached iframe to remain live as
it is passed between documents. This basically provides a shared code/state
repository across multiple pages. That said this may be a different model than
the existing module specifications?
I think something that needs to be cleared up is whether we expect modules to
be safely shared with untrusted code (i'm still not sure what people are
thinking about this). The general model in my mind is that each module would
be its own global object, with an api object that can be used to vend api to
whoever has a reference to the module. eg. a very ad hoc example, without to
much thought given to the API itself, just to describe the model
mymodule.js:
// Code encapsulated in the module
var bar = 4;
function sqr(x) { return x * x; }
function myFunction(foo) {
return sqr(foo * bar);
}
// Vend myFunction to the module api
APIObject.someAPI = myFunction
someCode.js:
// Get my module
mymodule = importModule("mymodule.js"); // This should be asynchronous
// A compelling use of an API
alert(mymodule.someAPI(4));
Anyhoo, i was just planning on bringing up this model at the f2f next week
--Oliver
>
> /be
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
