Mark S. Miller
erights at google.com
Mon Jan 18 12:27:43 PST 2010
On Mon, Jan 18, 2010 at 12:14 PM, Brendan Eich <brendan at mozilla.com> wrote:
> On Jan 18, 2010, at 11:58 AM, Mark S. Miller wrote:
> On Mon, Jan 18, 2010 at 10:25 AM, Brendan Eich <brendan at mozilla.com>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-126.96.36.199.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 never said they were. Whether Valija specifically is the right model for
separating primordial mutation, we can of course argue about. But first, I'm
still trying to understand your meaning. Would you agree that the Valija
sandbox is an example of the concept you are calling "module" above? If so,
then fine. Obviously, given the investment we've made in Valija, I am not
opposed to that model. If not, then I still do not understand your meaning.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss