On Apr 2, 2011, at 4:33 PM, David Herman wrote:

> (We've talked a little bit about generalizing the `require' form to be an 
> expression operator that does a static module load, but I'm not sure whether 
> it hangs together.)

I don't see how we can reserve 'require' as a static (compile-time) 
pseudo-function or operator, given that identifier's uses in extant JS.

For Harmony migration we want early errors, but some uses of require would 
"look ok" even though coded to call something other than the new built-in.


>> The end goal is trying limit the number of new special things in the
>> language the developer needs to learn for modules. Ideally it would
>> be: "use 'module' to declare an inline module, then use require('')
>> inside it to get handles on other modules, and use var/let and
>> destructuring as you normally would".
> 
> For many cases, I think that's fine. But .* is an important convenience for 
> scripting. Also, FWIW, import is already reserved and has symmetry with 
> export, so it seems like a wasted opportunity to fill a natural space in the 
> grammar.

I would like to make a stronger case for 'import': it is a static binding form 
new in Harmony that we need for two reasons:

1. To make 'require' on the right a contextual keyword, if used (see above).

2. To make a static binding and fail if there is already a binding of the same 
name.

None of the existing binding forms do both of these. 'const' is closest to 
'import' and satisfies (2), plus it is reserved already -- and variously 
implemented (IIRC Opera equates it with 'var'!). But 'const' does not satisfy 
(1).

Does this sound right?

/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to