Fully agree on all counts.
Dave
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Brendan Eich <bren...@mozilla.com> wrote:
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
