Ecma does official HTML now.
/be
Tab Atkins Jr. wrote:
unofficial HTML version for everything.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Tab Atkins Jr. wrote:
This group is public-script-coord, which we're already having the
discussion on, so... success!
THE SYSTEM IS WORKING!
Sorry for catch-up replies, I will try to stifle. ;-)
/be
___
es-discuss mailing list
Anne van Kesteren wrote:
On Thu, Apr 18, 2013 at 2:00 PM, Jorgejo...@jorgechamorro.com wrote:
You guys ought to be deeply embarrassed because HTML5 is *not* your child.
I don't even
http://www.whatwg.org/, remember?
https://brendaneich.com/2004/06/the-non-world-non-wide-non-web/,
Andreas Rossberg wrote:
I don't understand. Are you saying that it has a higher cost to
standardize a trivial convention than it is to standardize additional
ad-hoc syntax?
Answering for Dave: you bet it is.
The cost of the former is born by everyone in a large-N community who
must learn the
Tab Atkins Jr. wrote:
It would be so nice if JS had multiple return values, so we could let
cancellable future-returning APIs just return a naked resolver as
their second value,
Hello, destructuring:
let{ proxy, revoke} = Proxy.revocable(target, handler);
from
Le 20/04/2013 15:17, Brendan Eich a écrit :
Tab Atkins Jr. wrote:
It would be so nice if JS had multiple return values, so we could let
cancellable future-returning APIs just return a naked resolver as
their second value,
Hello, destructuring:
let{ proxy, revoke} = Proxy.revocable(target,
David Bruant wrote:
Le 20/04/2013 15:17, Brendan Eich a écrit :
Tab Atkins Jr. wrote:
It would be so nice if JS had multiple return values, so we could let
cancellable future-returning APIs just return a naked resolver as
their second value,
Hello, destructuring:
let{ proxy, revoke} =
Brendan Eich wrote:
Can't we all just get alone?
Oh, the irony! Typo, not snark :-).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I'm not seeing what in this proposal can't be implemented in
JavaScript as it is today. Is there an implementation of this
somewhere? Are there any programs that use these streams?
On Mon, Apr 15, 2013 at 9:19 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Apr 15, 2013 at 5:26 PM,
The cost of the former is born by everyone in a large-N community who must
learn the trivial convention. The cost of the latter is born by we few
TC39ers and JS implementors, who can make that sacrifice.
Yeah, but it's a false dilemma, I think. No trivial naming convention is
necessary, and
On Sat, Apr 20, 2013 at 6:17 AM, Brendan Eich bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
It would be so nice if JS had multiple return values, so we could let
cancellable future-returning APIs just return a naked resolver as
their second value,
Hello, destructuring:
let{ proxy,
On Sat, Apr 20, 2013 at 9:19 AM, Isaac Schlueter i...@izs.me wrote:
I'm not seeing what in this proposal can't be implemented in
JavaScript as it is today. Is there an implementation of this
somewhere? Are there any programs that use these streams?
This is a fully-general counter-argument
* Tab Atkins Jr. wrote:
On Sat, Apr 20, 2013 at 9:19 AM, Isaac Schlueter i...@izs.me wrote:
I'm not seeing what in this proposal can't be implemented in
JavaScript as it is today. Is there an implementation of this
somewhere? Are there any programs that use these streams?
This is a
On Sat, Apr 20, 2013 at 1:23 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Tab Atkins Jr. wrote:
On Sat, Apr 20, 2013 at 9:19 AM, Isaac Schlueter i...@izs.me wrote:
I'm not seeing what in this proposal can't be implemented in
JavaScript as it is today. Is there an implementation of this
On Sat, Apr 20, 2013 at 3:47 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Sat, Apr 20, 2013 at 9:19 AM, Isaac Schlueter i...@izs.me wrote:
I'm not seeing what in this proposal can't be implemented in
JavaScript as it is today. Is there an implementation of this
somewhere? Are there
__proto__ can be globally switched off by deleting Object.prototype.__proto__.
I’m assuming that that is useful for security-related applications (Caja et
al.). But I’m wondering: doesn’t that go too far? I’m seeing three ways of
using __proto__:
1. Read the [[Prototype]] of an object. Already
+1 to everything, but I would drop the literal too instead of promoting two
ways to do things.
off topic: I also hope __proto__ will be spec'd with a descriptor that
exposes the setter as it is now in Firefox, and not only the getter, as
conceptual language nonsense/restriction.
On Sat, Apr 20,
On Sat, Apr 20, 2013 at 1:54 PM, Brendan Eich bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
This group is public-script-coord, which we're already having the
discussion on, so... success!
THE SYSTEM IS WORKING!
Sorry for catch-up replies, I will try to stifle. ;-)
For what it's worth,
On Sat, Apr 20, 2013 at 4:13 PM, Sean Silva sil...@purdue.edu wrote:
On Sat, Apr 20, 2013 at 3:47 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Sat, Apr 20, 2013 at 9:19 AM, Isaac Schlueter i...@izs.me wrote:
I'm not seeing what in this proposal can't be implemented in
JavaScript as it
On Apr 20, 2013, at 10:36 AM, Kevin Smith zenpars...@gmail.com wrote:
Yeah, but it's a false dilemma, I think. No trivial naming convention is
necessary, and no ad-hoc syntax is necessary. Asking the developer to name a
thing with a well-chosen identifier is completely reasonable in my
On Sat, Apr 20, 2013 at 8:10 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Sat, Apr 20, 2013 at 4:13 PM, Sean Silva sil...@purdue.edu wrote:
On Sat, Apr 20, 2013 at 3:47 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Sat, Apr 20, 2013 at 9:19 AM, Isaac Schlueter i...@izs.me wrote:
On Apr 20, 2013, at 5:17 AM, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
I don't understand. Are you saying that it has a higher cost to
standardize a trivial convention than it is to standardize additional
ad-hoc syntax?
Answering for Dave: you bet it is.
The cost
I don't really know how to answer opinions like this. It just seems
like... it's fine that you feel that way, but kind of irrelevant.
Significant communities of JS developers have already spoken -- in words
and in precedent -- that they disagree with you. So for both smoother
In particular, I'd love to get TC39 to look over the is-a-future
issue. I'm pretty worried about the current solution which makes
then a magic property name. It's less bad than __proto__ is, but
not by a lot.
I agree - I'm putting together a list of a few issues with Futures that I
would
Kevin Smith wrote:
- Supporting anonymous exports makes the model a little more
complicated. We can quantify that with number of productions, or
lines of pseudo-code, or whatever you like, but that's a fact. All
else being equal, simple is better.
You're counting the wrong beans. Languages
(Thanks to Rick Waldron and Brendan Eich for encouragement towards posting
this)
As we see on es-discuss, the pressure towards standardizing soon various
features currently absent from ES6 is increasing. Rather than stretch ES6,
I think we should work towards completing ES6 asap, and then proceed
No, the argument is that users shouldn't have to name the anonymous export
and import by that name.
I understand, I'm just not convinced. I'm still on the fence.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
This looks lovely.
The only thing I'd want to add: we need integers! And generally better numeric
types. From speaking to developers on the ground, this is the biggest missing
language feature they see (that isn't already addressed in ES6). I know Brendan
has made some moves in this direction
28 matches
Mail list logo
