Mark S. Miller wrote:
> On Mon, Aug 18, 2008 at 1:44 PM, <[EMAIL PROTECTED]> wrote:
>> Consider a module file located at the URL --
>>
>> http://foo.com/someModule.js
>>
>> containing the text --
>>
>> var isOn = false;
>> provide
>> toggle: function() {
>> document.setBackgroundColor(isOn ?
>> background : '#ffffff');
>> isOn = !isOn;
>> },
>> set: function() {
>> document.setBackgroundColor(background);
>> isOn = true;
>> };
>>
>> This code has two free variables, "document" and "background", and
>> returns the symbols "toggle" and "set" to the importer.
I really like the general approach and the simplicity of Ihab's proposal.
Also I strongly agree that a module should *not* implicitly capture
the lexical scope in which it is imported.
I'm not sure why 'provide' needs new syntax, though. What's wrong with
module(function() {
var isOn = false;
return {
toggle: ...,
set: ...
};
});
or
var isOn = false;
provide({
toggle: ...,
set: ...
});
?
> I'll note that JavaScript seems strangely in between being an
> expression language and a statement language. For most purposes,
> statements are evaluated only for effect, not value. However, a
> program evaled as a string yields a value as one would expect of an
> expression language.
[...]
> If we decide that a module body is to be treated as an evaled program,
> then Ihab's example above can be simply: [...]
The fact that eval does things differently to the fragment of the
language without eval, doesn't mean that it is a good idea to rely
on those differences when designing new language features.
--
David-Sarah Hopwood
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
