On Tue, Jul 1, 2014 at 10:28 PM, Kevin Smith zenpars...@gmail.com wrote:
As such, we are balancing the marginal user experience gains of
export-overwriting against the better support for circular dependencies
of real modules.
Another way of looking at it:
Being in control of the
Thank you very much for the information.
On Tue, Jul 1, 2014 at 9:27 AM, Mark S. Miller erig...@google.com wrote:
I would like to see us take a principled stance on resource exhaustion
errors in ES7. This includes both stack and heap, and both space and time.
For example, the browser
If writing 'foo'.startsWith('foo') instead of 'foo'.indexOf('foo')==0 worth extending String's prototype (which IS a big deal), another math constant is worth it (since it is actually useful, see Rick's googling results). If _javascript_ was a language with tiny api, yes, your argument will hold.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello everyone!
While working on bn.js, I have found one bottleneck in integer
multiplication
which could be solved with introduction of a new Math functions.
In [multiply operation][0] the most expensive part is obviously an integer
multiplication.
Does the BNF grammar for ECMAScript in the specification licensed under BSD
license? The license says that software (code) is BSD-licensed. BNF grammar
is machine-readable and -executable, is it software?
___
es-discuss mailing list
Dear Kalinni Gorzkis,
I'm curious to what you're hoping to achieve here. This is not your
first email to this thread, and by searching on the web, I see you're
sending a lot of related messages to various other language groups and
what not. This makes me doubt you're actually interested in using
Actually, I just discovered [Vyacheslav's post on this list][0].
Looks like my proposal has not much to offer, comparing to his.
Thanks anyway!
[0]: https://www.mail-archive.com/es-discuss%40mozilla.org/msg27237.html
On Wed, Jul 2, 2014 at 2:37 PM, Fedor Indutny fe...@indutny.com wrote:
But it's neither simple nor solid. It's overtly complicated to support
features that shouldn't be there.
I have to disagree here. If we drop default imports, then we can describe
the module system like this:
Variables can be exported by name. Variables can be imported by name.
It doesn't
Another helpful place for a hook might be an executeDependencies type
thing, currently the list of dependencies returned by instantiate are all
loaded and ensureEvaluated is run on them, this makes sense for ES6 modules
which always evaluate all dependencies before the module that depends on
them,
circular dependencies in CJS are much easer then that
https://gist.github.com/calvinmetcalf/57be20b8eda0ee8fe6de
On Wed, Jul 2, 2014 at 4:09 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Tue, Jul 1, 2014 at 10:28 PM, Kevin Smith zenpars...@gmail.com wrote:
As such, we are
circular dependencies in CJS are much easer then that
https://gist.github.com/calvinmetcalf/57be20b8eda0ee8fe6de
Umm... I would rather call that tricky as hell ; )
___
es-discuss mailing list
es-discuss@mozilla.org
circular dependencies in CJS are much easer then that
https://gist.github.com/calvinmetcalf/57be20b8eda0ee8fe6de
Umm... I would rather call that tricky as hell ; )
Besides, it fails if you do `require(./b)`, IIUC.
___
es-discuss mailing list
I agree with everything Jussi wrote. He gets to the heart of the issue.
The points that have been previously made about bundling modules also
apply to REPLs. If a module must be in a file, I can't easily define
modules at a REPL prompt.
--scott
___
This is not a character-count issue, neither a is mathematically
calculable issue. It's a readability and maintainability issue. When
developing games we have 3 options:
1. Use Math.PI * 2 everywhere
2. Create a TAU constant on every file
3. Create a TAU constant on a single file and require
The arguments for and against supporting cyclic dependencies seem to be
academic. I'm yet to see any evidence of their importance in practice nor
proof they they are fundamental ... or not.
I wouldn't say that cyclic dependencies are academic, in the sense of not
real. If they are allowed
On Wed, Jul 2, 2014 at 7:09 PM, John Barton johnjbar...@google.com wrote:
* (Reliably) statically analyzable syntax. This is my favourite feature
and really awesome. Allows engine to fetch next modules while the current
one is still being parsed,
This isn't true -- all module designs in
You can of course assume that the require call with a static string does
what you'd expect but then you might end up loading something that was
never actually required but someone had their own require function there
instead that has something else.
This is a solved problem actually
This seems like a bit too many issues, so let me just correct one
(important) one.
On Wed, Jul 2, 2014 at 2:09 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Wed, Jul 2, 2014 at 7:09 PM, John Barton johnjbar...@google.com
wrote:
Now, I know there are people that think that
On 6/24/14, 9:51 AM, Domenic Denicola wrote:
I'd be interested in collaborating on designing such a language extension.
I think I would too; I'm just not sure about availability.
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
Le 27 juin 2014 à 15:56, Claude Pacheclaude.pa...@gmail.com a écrit :
Here is a counter-proposal (or an improved
proposal, ad libidum), which is not tightly coupled to @@new.
This proposal seems ok to me from my DOM-centric perspective. ;)
Optional: the @@create hook
On Wed, Jul 2, 2014 at 3:38 PM, Kevin Smith zenpars...@gmail.com wrote:
But it's neither simple nor solid. It's overtly complicated to support
features that shouldn't be there.
I have to disagree here. If we drop default imports, then we can describe
the module system like this:
The arguments for and against supporting cyclic dependencies seem to be
academic. I'm yet to see any evidence of their importance in practice nor
proof they they are fundamental ... or not.
Transitive cyclic dependencies. I'd say that's the case that was in
the minds of the authors of the
On Wed, Jul 2, 2014 at 3:29 PM, Brian Di Palma off...@gmail.com wrote:
The arguments for and against supporting cyclic dependencies seem to be
academic. I'm yet to see any evidence of their importance in practice nor
proof they they are fundamental ... or not.
Support for them is needed,
I know that this subject has been beaten and tortured to the point it would
be a bloody corpse if a living being, but I don't recall one specific
aspect being addressed so far:
How will legacy modules (CommonJS, AMD, browser window variable, etc.) be
supported in ES6 imports?
Would it be a
24 matches
Mail list logo
