On Thu, Jul 3, 2014 at 1:29 AM, 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.
Transitive cyclic
On Wed, Jul 2, 2014 at 5:52 PM, A Matías Quezada amati...@gmail.com wrote:
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 this file from
everywhere just for this
4. Do Math.TAU = Math.PI * 2 once somewhere. It even
SystemJS seems the best approach at the moment.
https://github.com/systemjs/systemjs/
The ES6 module loader shouldn't have any built in knowledge of these
other specs.
It should be up to us to use loaders that are patched to understand
these legacy module systems.
Or we could compile these
So sometimes someone can need it, so we must have good support? Is that how
we operate these days?
Imagine a large codebase which already has transitive cyclic dependencies.
If the module system has poor support for them it might still work
with them until one day a developer reordered the
On Thu, Jul 3, 2014 at 11:41 AM, Brian Di Palma off...@gmail.com wrote:
So sometimes someone can need it, so we must have good support? Is that
how we operate these days?
Imagine a large codebase which already has transitive cyclic dependencies.
If the module system has poor support for
Extending host objects? I don't think that favors readability and
maintainability.
If I don't know TAU (or some one read my code and doesn't know it) and see
this I will look for Math.TAU on MDN, not on the project and if by chance I
guess it's defined somewhere in the project how will I know?
PS: Also in ES6 modules it will be not possible to extend module Math.
---
A. Matías Quezada
Senior Javascript Developer
amati...@gmail.com
2014-07-03 15:02 GMT+02:00 A Matías Quezada amati...@gmail.com:
Extending host objects? I don't think that favors readability and
maintainability.
If
On Jul 3, 2014 9:15 AM, A Matías Quezada amati...@gmail.com wrote:
PS: Also in ES6 modules it will be not possible to extend module Math.
Really? That will be quite problematic when it comes time to write es7-shim.
--scott
___
es-discuss mailing list
On Thu, Jul 3, 2014 at 2:31 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
Tools like Traceur can support it for an easier migration path since they
already have diverged from ES.next anyway with all the annotations (for
which, off topic, I haven't seen even a proposal here yet)
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-module-objects
A Module object is an exotic object whose own properties corresponding
corresponding to the ExportedBindings of the module identifed by the
ModuleImport FromClause. Each property name is the StringValue of
That doesn't mean that you cannot extend builtins - if you don't explicitly
load a module into its own Realm using the ModuleLoader, it shares builtins
with all other modules.
Also note that a Module object isn't the scope for a module script. It's a
reflection of the internal metadata about the
On Thu, Jul 3, 2014 at 5:42 PM, John Barton johnjbar...@google.com wrote:
On Thu, Jul 3, 2014 at 2:31 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
Tools like Traceur can support it for an easier migration path since
they already have diverged from ES.next anyway with all the
Till: we can discuss that on another thread, we are missing the main point
here...
---
A. Matías Quezada
Senior Javascript Developer
amati...@gmail.com
2014-07-03 17:09 GMT+02:00 Till Schneidereit t...@tillschneidereit.net:
That doesn't mean that you cannot extend builtins - if you don't
Here is an updated version of my proposal. Superficially, there are notable
changes on how the things are presented, but the observable behaviour remains
basically the same.
For a quick understanding, the Simple Description should suffice.
In the Detailed Semantics, I’ve tried to give just
Hi,
Will it makes sense to standardize a trailing comma for function arguments,
and call parameters?
We have it for Array and Object initialisers, and people like using them
for long lists with prediction of new items adding in the future:
```
var modes = [
read,
write,
];
var platforms =
15 matches
Mail list logo
