I cannot agree with Andreas more. In my opinion, module registrations
should not be used as an authoring format, but only as a target for tooling
(specifically multiplexers).
In any case, I don't see how there is _true_ consensus around this issue at
this time, nor do I see that anything is set
Yep, agreed. (To be pedantic, it's not that it defers execution so much as
that it doesn't force execution.)
Can you explain? I would naively expect for this:
// someModule
console.log(someModule);
// main
import someModule;
console.log(main);
when executing main, to
That appears to be disallowed; I believe
{ ImportSpecifier (, ImportSpecifier)* ,? }
requires at least one `ImportSpecifier`.
Oversight. Fixed.
Looks good, but I'm thinking that this should probably _not_ be allowed:
import {,} from x;
{ Kevin }
On Tue, Jun 4, 2013 at 9:22 AM, Kevin Smith zenpars...@gmail.com wrote:
- The semantics of lexical modules are not really in dispute
This is not correct. Andreas, Dave, and I spend a lot of time working
on the semantics of lexical modules, and there are significant
difficulties. If you get rid
This is not correct. Andreas, Dave, and I spend a lot of time working
on the semantics of lexical modules, and there are significant
difficulties. If you get rid of recursion, and if modules cannot be
exported from other modules, and then imported from, then things are
easier, but I don't
On Tue, Jun 4, 2013 at 9:45 AM, Andreas Rossberg rossb...@google.com wrote:
On 4 June 2013 15:31, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Tue, Jun 4, 2013 at 9:22 AM, Kevin Smith zenpars...@gmail.com wrote:
- The semantics of lexical modules are not really in dispute
This is not
Something that occurred to me today is that we have methods for locking
down objects in different ways except for preventing changes to existing
properties. We have:
- Object.seal to prevent new properties being added or existing properties
being deleted
- Object.preventExtensions to prevent
Well, it's unclear to me exactly what semantics Kevin was proposing,
but the current system has export * from ... and this introduces
many of the same problems once you import and export modules.
And the complexity of the static semantics is what I'm trying to point
out, fundamentally.
We
On Tue, Jun 4, 2013 at 6:29 AM, Kevin Smith zenpars...@gmail.com wrote:
Yep, agreed. (To be pedantic, it's not that it defers execution so much
as that it doesn't force execution.)
Can you explain? I would naively expect for this:
// someModule
console.log(someModule);
//
From: Yehuda Katz [wyc...@gmail.com]
In general, expectations about side-effects that happen during module loading
are really edge-cases. I would go as far as to say that modules that produce
side effects during initial execution are doing it wrong, and are likely to
produce sadness.
In
On Mon, Jun 3, 2013 at 11:33 AM, Yehuda Katz 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
On Tue, Jun 4, 2013 at 8:11 AM, Jason Orendorff
jason.orendo...@gmail.comwrote:
On Mon, Jun 3, 2013 at 11:33 AM, Yehuda Katz 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
2013/6/4 Yehuda Katz wyc...@gmail.com
On Tue, Jun 4, 2013 at 8:11 AM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On Mon, Jun 3, 2013 at 11:33 AM, Yehuda Katz wyc...@gmail.com wrote:
I've advocated for this in the past. I believe it should be allowed.
Separately, I would like this
In this case, the `import` statement is just asking the module loader to
download someModule, but allowing the app to move on with life and not
bother executing it. This would allow an app to depend on a bunch of
top-level modules that got executed only once the user entered a particular
On Tuesday, June 4, 2013, Yehuda Katz wrote:
On Tue, Jun 4, 2013 at 8:11 AM, Jason Orendorff
jason.orendo...@gmail.comjavascript:_e({}, 'cvml',
'jason.orendo...@gmail.com');
wrote:
On Mon, Jun 3, 2013 at 11:33 AM, Yehuda Katz
wyc...@gmail.comjavascript:_e({}, 'cvml',
Object.defineProperty(myArray, length, {writable: false});
A writable, non-configurable property can still be set to non-writable.
Allen
On Jun 4, 2013, at 6:57 AM, Andy Earnshaw wrote:
Something that occurred to me today is that we have methods for locking down
objects in different ways
On Jun 4, 2013, at 6:31 AM, Kevin Smith zenpars...@gmail.com wrote:
Looks good, but I'm thinking that this should probably _not_ be allowed:
import {,} from x;
Right you are! Fixed, thanks.
Dave
___
es-discuss mailing list
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
Le 04/06/2013 06:57, Andy Earnshaw a écrit :
Something that occurred to me today is that we have methods for
locking down objects in different ways except for preventing changes
to existing properties. We have:
- Object.seal to prevent new properties being added or existing
properties
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
On Tue, Jun 4, 2013 at 11:37 AM, Jeff Morrison lbljef...@gmail.com 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
On Tue, Jun 4, 2013 at 11:44 AM, Jeff Morrison lbljef...@gmail.com wrote:
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()
On Tue, Jun 4, 2013 at 8:02 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Yehuda Katz [wyc...@gmail.com]
In general, expectations about side-effects that happen during module
loading are really edge-cases. I would go as far as to say that modules that
produce side effects
On 6/4/13 9:52 AM, Jason Orendorff wrote:
On Tue, Jun 4, 2013 at 11:44 AM, Jeff Morrison lbljef...@gmail.com
mailto:lbljef...@gmail.com wrote:
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()
Le 04/06/2013 11:24, Andy Earnshaw a écrit :
I'm not sure I understand what you're saying here. Do you want to
return the same or a different object? For sure, your caller will
know if you returned a different object (because it can compare
the argument and the return value)
On Wed, Jun 5, 2013 at 12:51 AM, Mark S. Miller erig...@google.com wrote:
I am making here only an argument that .then's result behavior should be
flatMap-like rather than .map-like. As for which of these the .chain camp
prefers for .chain's result behavior, I am neutral. But if they choose
26 matches
Mail list logo
