(I get the digest...)
First, I will say that you all beat me to my (almost) exact suggestion on
the syntax, @Russell and @Scott.
Second, `module foo from 'foo'` is counterintuitive, confusing,
non-obvious, and really needs trashed IMHO.
Now, to supplement these ideas, I will summarize how I
I fully admit that I'm probably hanging a little behind in terms of emails
because I get them bundled into 4-5 each.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I propose the tau constant be added to the Math object and be defined as
2*Math.PI, as described in the tau manifesto:
http://tauday.com/tau-manifesto
(I couldn't find any discussion about this when searching esdiscuss.org, so
sorry if this has been discussed before)
Marius Gundersen
Why make things so complex and introduce so many syntax variations? The
following should be sufficient:
import underscore as _; // var _ = require('underscore');
And there should be an API (not a language construct) to import a module
dynamically (and asynchronously). Something like:
promise =
I like it! Cc'ing others who may have missed it. Boris is DOM guru you seek.
Does it address the bound function issue you cited in the previous
thread? It appears not to, but I might be missing something (jetlag).
/be
Claude Pache wrote:
Please do the following substitutions in my message:
Brendan Eich wrote:
I like it! Cc'ing others who may have missed it. Boris is DOM guru you
seek.
Forgot to suggest a better spec-name: Pre-constructed instead of
Non-Constructed.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
This would give the same power / flexibility as CommonJS and a simple
compatibility path. This would eliminate the default exports problem
because it would allow a module to export a function. It is also easy to
explain.
So this is basically the sugar over CommonJS modules solution. But
On Sat, Jun 28, 2014 at 9:03 AM, Kevin Smith zenpars...@gmail.com wrote:
Static checking on exported members feels odd.
Static checking of imports and exports has well-known advantages and would
help the long-term viability of the language.
Enumerating these specific advantages would
What if the Loader spec had some attention given to match AMD/CommonJS for
some cases and leave the new syntax for the new module semantics. Really
what we want is for non-es6 module systems to be able to hook into the
loader registry in a way that makes sense for them and will also make sense
for
On Saturday, June 28, 2014, Brendan Eich bren...@mozilla.org wrote:
Ok, nerdbait -- but I'll take it and champion it at the next TC39 meeting.
Thanks,
Yes, if you hadn't I would've :)
I doubt there will be an opposition, but for anyone interested, Section 2
(especially 2.1) of the Tau
Static checking of imports and exports has well-known advantages and
would help the long-term viability of the language.
Enumerating these specific advantages would inform this discussion. These
advantages are not well-known. Many developers have experienced the
disadvantages of complex
Le 28 juin 2014 à 17:49, Brendan Eich bren...@mozilla.org a écrit :
I like it! Cc'ing others who may have missed it. Boris is DOM guru you seek.
Does it address the bound function issue you cited in the previous thread? It
appears not to, but I might be missing something (jetlag).
It
This looks nice to me as well. But given the length I had trouble internalizing
in what externally-visible ways it would change the status quo, especially with
the optional @@create addition. The writeup as-is is very
spec-language-focused. Would it be simple to summarize that for us?
There's
Static checking will be limited anyway. If you want to go this way you shoud
use typescript.
Big projects are perfectly manageable with CommonJS from my experience with a
20+ team. The trick is to enforce code reviews and unit tests.
CommonJS falls a bit short on the import side because
Maybe, I cannot see all the landscape, but a minor comment, in my limited
English
Related to:
## Early Errors and Warnings ##
Usually, I obtain the same benefit running the tests (and more, test that
were the product of TDD workflow). In this way, I'm sure not only of no
removal of something I
Static checking will be limited anyway. If you want to go this way you
should use typescript.
That's the point that I'm trying to make, shops will choose other languages
that provide more static information. We should be thinking about
expanding the user base and ensuring that JS is a viable
FYI: http://www.thepimanifesto.com/
On Sat, Jun 28, 2014 at 9:28 AM, Marius Gundersen gunder...@gmail.com
wrote:
I propose the tau constant be added to the Math object and be defined as
2*Math.PI, as described in the tau manifesto:
http://tauday.com/tau-manifesto
(I couldn't find any
Usually, I obtain the same benefit running the tests (and more, test that
were the product of TDD workflow). In this way, I'm sure not only of no
removal of something I needed, but also the underlying behavior of imported
modules are still the same. Relaying on static imports only warns me
I'll admit to being a pi-ist, rather than a tau-ist, but I don't object to
adding Math.TAU. It's a fairly harmless easter egg.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Thanks Claude for working this up.
InitializeThisBindings(nonconstructedObj, obj) abstract operation
--
This operation performs the actual initialisation of the this-bindings
that were previously deferred:
1. Assert
20 matches
Mail list logo
