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).
-Jeff
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 <wyc...@gmail.com
<mailto:wyc...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
