Minor questions on new module BNF

Jeff Morrison lbljeffmo at gmail.com
Tue Jun 4 09:44:45 PDT 2013

FWIW this is what we have been doing at Facebook for a while now (over a 
year), and it's worked pretty well for us.

We use a require() function for pulling in dependencies. We then 
statically extract all require() callsites for a given module during our 
build step, and use that to identify the dependency-graph of a file (for 
packaging, etc).


On 6/4/13 9:37 AM, Jeff Morrison wrote:
> I still kinda like the idea of allowing ImportDeclarations to be 
> expressed anywhere inside a ScriptElement (including in its children), 
> and then hoisting the declaration for compilation/linking, but only 
> executing the dependency when the statement is reached at runtime. It 
> is then a parse error if an ImportDeclaration is outside of a 
> ScriptElement context.
> The System.get() paradigm is kind of awkward and indistinguishable 
> from the import syntax in terms of its expressive relation.
> If its all we can get, so be it -- but it feels pretty unpolished.
> -Jeff
> On 6/4/13 8:11 AM, Jason Orendorff wrote:
>> On Mon, Jun 3, 2013 at 11:33 AM, Yehuda Katz <wycats at gmail.com 
>> <mailto:wycats at gmail.com>> wrote:
>>     I've advocated for this in the past. I believe it should be allowed.
>>     Separately, I would like this form to be specified as deferring
>>     execution until bindings are explicitly imported (from another
>>     module), or a synchronous `System.get` call is made.
>> It makes the static import language a bit more expressive, but why is 
>> it necessary?
>> For performance? The alternative, if a module has expensive 
>> initialization, would be to have it initialize itself more lazily.
>>     This would make it possible to guarantee that a synchronous
>>     `System.get` will succeed, without being forced to execute the
>>     module first.
>> It would definitely make that possible, but what `System.get()` use 
>> case are you looking to support? To my mind `System.get()` is like 
>> examining `$LOADED_FEATURES` in Ruby or `sys.modules` in Python; 
>> those use cases exist, but the kind of code you're writing when you 
>> touch those is typically either an egregious hack or it's generic 
>> across all modules, right? They don't need or merit syntactic support.
>> I want to understand the motivation, because Domenic asked for syntax 
>> that just loads and runs a module, without bindings. It seems like we 
>> could support that feature with a tweak of the grammar, but you're 
>> proposing taking that exact syntax and using it for something else. I 
>> expect people trying to load and run a module will greatly outnumber 
>> people trying to load and *not* run a module.  Wouldn't we be 
>> astonishing more people by doing it your way?
>> -j
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130604/1f0a88b0/attachment-0001.html>

More information about the es-discuss mailing list