Minor questions on new module BNF
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
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.
> 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?
>> es-discuss mailing list
>> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss