Re: ... A community is writing the spec...
nope, looks like you forgot (sad) parenthesis :P
My point was that Array extras have this second argument there to pass a
context and fat arrow, as opposite of the thin one, would make that
parameter misleading/confusing/pointless (same as bind would but fat makes
it easier to mistake the intent)
You know I wish thin arrow would have made it in ES6 as just exactly a
function shortcut as we know it since ever, nothing to spec if not its -
syntax, much more use cases covered for all tastes.
Now I think we should (I will) leave this thread which intent is at this
point unclear :-)
Alex ... you can't really subclass Arrays without redefining slice, splice,
concat, and others behavior ending up loosing your initial type and I've
been writing sublcassing tricks since 2008
You can inject the proto but that's not really subclassing ... about tuning
performance, it's not just that, it's convenient to pass dictionaries,
maps, or parameters in there without binding because binding is indeed not
needed since the second argument is the context as specs say.
If you bind the callback ask yourself why is that ... you probably chose to
use half of the potential of the Array method for no reason.
Best Regards
On Thu, Sep 11, 2014 at 1:43 AM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Sep 10, 2014 at 4:14 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
with all due respect Rick, and you know we've been talking about this
already, your forEach = example assumes you have created a subclassed
Array ... which trust me, it's the least common case you gonna have in the
real world 'cause basically impossible before ES6.
An implementation detail, don't nitpick.
// Call a method of this object or class or whatever to make Andrea
happy with my example
var happies = sads.map(sad = this.makeAndreaHappy(sad));
That work for you?
Everybody else that used to pass a different context to do something more
meaningful would fall in that trap at least once.
Of course they will learn their mistakes ... but please don't use
forEach as example about how cool is fat arrow 'cause in my opinion, with
Array extras, that's actually a perfect place where fat arrows is the most
confusing.
Regards
On Wed, Sep 10, 2014 at 6:58 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Sep 10, 2014 at 8:17 AM, Alexandre Morgaut
alexandre.morg...@4d.com wrote:
Hi,
The way this discussion started looked very troll oriented, but let
comment few things I more or less agree or not with
What I see is more functionality of the browser api then an actually
language.
I actually work for 4D that provide JavaScript on the server in its
Wakanda Server which is not using node.js (at least for now)
I have to disagree with this statement as I see very good added value
in ES6 for our developers on server-side
And I look into node promise and the spec promise on MDN... And I'm
still not seeing the big picture. Could you give me a brief in your own
words
I think the first place I saw Promise as a specification for JavaScript
was on the CommonJS mailing list and wiki
http://wiki.commonjs.org/wiki/Promises
Then on WHATWG, first called Future (not anymore online) and via this
github repository
https://github.com/slightlyoff/Promises/tree/master/historical_interest
Then in W3C drafts
http://www.w3.org/TR/2013/WD-dom-20131107/#promises
http://heycam.github.io/webidl/#idl-promise
Before finally going into JS core, then in ECMAScript
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects
An interesting blog post about Promise history in JS:
https://infrequently.org/2013/06/sfuturepromiseg/
It intends to make life better when chaining async callback calls which
is absolutely not browser specific
It may have stay as a library, but then no Specification call rely on
it, and many actually upcoming HTML5 features choose to rely on it
And this stupid ()={} arrow function... After seeing this I got the
ideal of letting functions follow the same rules as for, if, while... That
if it's one line of code, than let it be:
function add(arg0) console.log(arg++);
With out a body --curly braces--... Funny thing is that Firefox allow
this syntax style.
var arr = [];
[0,1,2,3].forEach(function(arg0)arr.push(100+arg0));
arr;
Copy paste in Firefox to see.
I'm not big fan neither of fat arrow functions because:
- the code looks less expressive to me, code becomes very cryptic for
anyone that don't know them and confusing as potentially associated to
+=, *=, ...
There is nothing ambiguous about `=` with regard to existing compound
assignment operators.
- they have no room for a function name that would be useful in
debugger stacks and closure scope names, or profilers function call counts
Still beware those are not only about syntax but also have different
behaviors. The binding of this is different
I admit I fear more confusion
Re: {Spam?} Re: ... A community is writing the spec...
but only one made it ... I am not comparing but many developers are already confused about fat not behaving like thin. Yes, thin should be part of ES6 ... it's way easier to spec as just regular anonymous `function` shortcut , I still don't understand why it has been left out. The `function` AFAIK was the boring/too long problem to sugar, we've got 3 other ways to define it in other flavors and yet not a shortcut as thin arrow would simply be. Best Regards On Thu, Sep 11, 2014 at 2:21 AM, Brendan Eich bren...@mozilla.org wrote: Alex Kocharin wrote: Everybody else that used to pass a different context to do something more meaningful Does anyone really do that? Except for fine-tuning performance? As far as I remember, people either use closures or .bind() stuff. Yup. Andrea, if you want - (which you do) can you kindly stop complaining that = is not -? That's like saying blue cheese is bad because it isn't cheddar. Both are great! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: {Spam?} Re: ... A community is writing the spec...
for record sake, this is my complain on missingn - better explained: https://gist.github.com/qubyte/43e0093274e793cc82ba#comment-1292183 Rick kindly ensured me that it will be discussed for ES7, I see that too late for such little improvement able to cover 100% of use cases ( including `((x)-x)).bind(ctx)` ) Not sure what to do to make it happen sooner. Best Regards On Thu, Sep 11, 2014 at 9:21 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: but only one made it ... I am not comparing but many developers are already confused about fat not behaving like thin. Yes, thin should be part of ES6 ... it's way easier to spec as just regular anonymous `function` shortcut , I still don't understand why it has been left out. The `function` AFAIK was the boring/too long problem to sugar, we've got 3 other ways to define it in other flavors and yet not a shortcut as thin arrow would simply be. Best Regards On Thu, Sep 11, 2014 at 2:21 AM, Brendan Eich bren...@mozilla.org wrote: Alex Kocharin wrote: Everybody else that used to pass a different context to do something more meaningful Does anyone really do that? Except for fine-tuning performance? As far as I remember, people either use closures or .bind() stuff. Yup. Andrea, if you want - (which you do) can you kindly stop complaining that = is not -? That's like saying blue cheese is bad because it isn't cheddar. Both are great! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
You can inject the proto but that's not really subclassing ... You know, I'm starting to think that injecting proto is actually the right way to do subclassing. It preserves [[Class]], it doesn't depend on `new`, etc. Here is some code I checked with: https://gist.github.com/rlidwka/0ad094386f60f93318bf If you bind the callback ask yourself why is that Because not every function in _javascript_ supports passing contexts, so you have to bind stuff anyway for other functions. So it makes sense to bind everything for consistency reasons. Also it's more convenient to have bound function as one variable that you can pass everywhere. 11.09.2014, 12:17, "Andrea Giammarchi" andrea.giammar...@gmail.com:nope, looks like you forgot (sad) parenthesis :P My point was that Array extras have this second argument there to pass a context and fat arrow, as opposite of the thin one, would make that parameter misleading/confusing/pointless (same as bind would but fat makes it easier to mistake the intent) You know I wish thin arrow would have made it in ES6 as just exactly a function shortcut as we know it since ever, "nothing to spec" if not its - syntax, much more use cases covered for all tastes. Now I think we should (I will) leave this thread which intent is at this point unclear :-) Alex ... you can't really subclass Arrays without redefining slice, splice, concat, and others behavior ending up loosing your initial "type" and I've been writing sublcassing tricks since 2008 You can inject the proto but that's not really subclassing ... about tuning performance, it's not just that, it's convenient to pass dictionaries, maps, or parameters in there without binding because binding is indeed not needed since the second argument is the context as specs say. If you bind the callback ask yourself why is that ... you probably chose to use half of the potential of the Array method for no reason. Best Regards On Thu, Sep 11, 2014 at 1:43 AM, Rick Waldron waldron.r...@gmail.com wrote:On Wed, Sep 10, 2014 at 4:14 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote:with all due respect Rick, and you know we've been talking about this already, your forEach = example assumes you have created a subclassed Array ... which trust me, it's the least common case you gonna have in the real world 'cause basically impossible before ES6. An implementation detail, don't nitpick. // Call a method of this object or class or whatever to make Andrea happy with my example var happies = sads.map(sad = this.makeAndreaHappy(sad)); That work for you? Everybody else that used to pass a different context to do something more meaningful would fall in that trap at least once. Of course they will learn "their" mistakes ... but please don't use forEach as example about how cool is fat arrow 'cause in my opinion, with Array extras, that's actually a perfect place where fat arrows is the most confusing. RegardsOn Wed, Sep 10, 2014 at 6:58 PM, Rick Waldron waldron.r...@gmail.com wrote:On Wed, Sep 10, 2014 at 8:17 AM, Alexandre Morgaut alexandre.morg...@4d.com wrote:Hi, The way this discussion started looked very troll oriented, but let comment few things I more or less agree or not withWhat I see is more functionality of the browser api then an actually language. I actually work for 4D that provide _javascript_ on the server in its Wakanda Server which is not using node.js (at least for now)I have to disagree with this statement as I see very good added value in ES6 for our developers on server-sideAnd I look into node promise and the spec promise on MDN... And I'm still not seeing the big picture. Could you give me a brief in your own words I think the first place I saw Promise as a specification for _javascript_ was on the CommonJS mailing list and wikihttp://wiki.commonjs.org/wiki/Promises Then on WHATWG, first called Future (not anymore online) and via this github repositoryhttps://github.com/slightlyoff/Promises/tree/master/historical_interest Then in W3C draftshttp://www.w3.org/TR/2013/WD-dom-20131107/#promiseshttp://heycam.github.io/webidl/#idl-promise Before finally going into JS core, then in ECMAScripthttp://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects An interesting blog post about Promise history in JS:https://infrequently.org/2013/06/sfuturepromiseg/ It intends to make life better when chaining async callback calls which is absolutely not browser specificIt may have stay as a library, but then no Specification call rely on it, and many actually upcoming HTML5 features choose to rely on itAnd this stupid ()={} arrow function... After seeing this I got the ideal of letting functions follow the same rules as for, if, while... That if it's one line of code, than let it be: function add(arg0) console.log(arg++); With out a body --curly braces--... Funny thing is that Firefox allow this syntax style. var arr = [];[0,1,2,3].forEach(function(arg0)arr.push(100+arg0));arr; Copy paste in Firefox to see. I'm
Re: ... A community is writing the spec...
This These feature--most of them-- would be something I see in the browser api... This is truly looking like w3c working group... ... But I don't see any chance of my words changing the direction of the spec Especially when you consider the original designer of the language steering this course... So in term, if you can't beat them, change them, might as well aid them --in what I feel to be In truth, the destruction of the original syntax, by the original creature of the language... Kinda wish they had a flag for these new syntax to be set... At least than, those who are toward the originally syntax style, would feel some sort of preservation for it-- In their quest to farther add on to ES as a --application-- language. --as duo to a private email by /be. This to me is not trolling, I'm responding to this person who respond two times to my post... So in terms, I should not have to worry about being banned from the mailing list cause of this message. E-S4L N-S4L On Sep 10, 2014, at 1:17 AM, Axel Rauschmayer a...@rauschma.de wrote: Now is second half of 2014, and lots of issues are not closed yet, from what I see. The spec already looks pretty complete to me and Traceur and TypeScript do a pretty good job of letting you use ES6 today. As previously announced here, the current schedule is to be finished by the end of the year, to start the publication process in March 2014 and to have a standard by June 2014. I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: It has already changed, but not for ES6. ECMAScript 7 and later will have fixed release dates. Only features that are ready at a given date will be included. Background: https://github.com/tc39/ecma262 -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
I don't see why you're complaining. If you don't like the features in ES6, then just don't use them. The features of ES5 are still available. If you want to have more strict code, then add a use strict; statement to your code. And if you're against adding more features to the core language, then you should have complained several years ago at the planning of ES6. Sebastian On 10 September 2014 08:12, L2L 2L emanuelal...@hotmail.com wrote: This These feature--most of them-- would be something I see in the browser api... This is truly looking like w3c working group... ... But I don't see any chance of my words changing the direction of the spec Especially when you consider the original designer of the language steering this course... So in term, if you can't beat them, change them, might as well aid them --in what I feel to be In truth, the destruction of the original syntax, by the original creature of the language... Kinda wish they had a flag for these new syntax to be set... At least than, those who are toward the originally syntax style, would feel some sort of preservation for it-- In their quest to farther add on to ES as a --application-- language. --as duo to a private email by /be. This to me is not trolling, I'm responding to this person who respond two times to my post... So in terms, I should not have to worry about being banned from the mailing list cause of this message. E-S4L N-S4L On Sep 10, 2014, at 1:17 AM, Axel Rauschmayer a...@rauschma.de wrote: Now is second half of 2014, and lots of issues are not closed yet, from what I see. The spec already looks pretty complete to me and Traceur and TypeScript do a pretty good job of letting you use ES6 today. As previously announced here, the current schedule is to be finished by the end of the year, to start the publication process in March 2014 and to have a standard by June 2014. I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: It has already changed, but not for ES6. ECMAScript 7 and later will have fixed release dates. Only features that are ready at a given date will be included. Background: https://github.com/tc39/ecma262 -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
Yeah I guess I'm pretty late for that huh... No this is great, the more feature, the better. A lot of these feature would cause certain application not to be needed... In other words, use more of the language and less libraries Why you at it, how about reviving E4X? That way, we can lose the DOM api. After all, if ES was made for the web, than there should be method to access the DOM. It could be an object, like how the E4X was, but better. On another note, this is now becoming the mini-type application/JavaScript, than text/JavaScript. But consider the E4X though. E-S4L N-S4L On Sep 10, 2014, at 9:35 AM, Sebastian Zartner sebastianzart...@gmail.com wrote: I don't see why you're complaining. If you don't like the features in ES6, then just don't use them. The features of ES5 are still available. If you want to have more strict code, then add a use strict; statement to your code. And if you're against adding more features to the core language, then you should have complained several years ago at the planning of ES6. Sebastian On 10 September 2014 08:12, L2L 2L emanuelal...@hotmail.com wrote: This These feature--most of them-- would be something I see in the browser api... This is truly looking like w3c working group... ... But I don't see any chance of my words changing the direction of the spec Especially when you consider the original designer of the language steering this course... So in term, if you can't beat them, change them, might as well aid them --in what I feel to be In truth, the destruction of the original syntax, by the original creature of the language... Kinda wish they had a flag for these new syntax to be set... At least than, those who are toward the originally syntax style, would feel some sort of preservation for it-- In their quest to farther add on to ES as a --application-- language. --as duo to a private email by /be. This to me is not trolling, I'm responding to this person who respond two times to my post... So in terms, I should not have to worry about being banned from the mailing list cause of this message. E-S4L N-S4L On Sep 10, 2014, at 1:17 AM, Axel Rauschmayer a...@rauschma.de wrote: Now is second half of 2014, and lots of issues are not closed yet, from what I see. The spec already looks pretty complete to me and Traceur and TypeScript do a pretty good job of letting you use ES6 today. As previously announced here, the current schedule is to be finished by the end of the year, to start the publication process in March 2014 and to have a standard by June 2014. I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: It has already changed, but not for ES6. ECMAScript 7 and later will have fixed release dates. Only features that are ready at a given date will be included. Background: https://github.com/tc39/ecma262 -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
Hi L2L, this message is uninformed that I must ask you to move to another forum, until you learn a lot more about js and web programming. This is not the place. On Sep 10, 2014 6:47 AM, L2L 2L emanuelal...@hotmail.com wrote: Yeah I guess I'm pretty late for that huh... No this is great, the more feature, the better. A lot of these feature would cause certain application not to be needed... In other words, use more of the language and less libraries Why you at it, how about reviving E4X? That way, we can lose the DOM api. After all, if ES was made for the web, than there should be method to access the DOM. It could be an object, like how the E4X was, but better. On another note, this is now becoming the mini-type application/JavaScript, than text/JavaScript. But consider the E4X though. E-S4L N-S4L On Sep 10, 2014, at 9:35 AM, Sebastian Zartner sebastianzart...@gmail.com wrote: I don't see why you're complaining. If you don't like the features in ES6, then just don't use them. The features of ES5 are still available. If you want to have more strict code, then add a use strict; statement to your code. And if you're against adding more features to the core language, then you should have complained several years ago at the planning of ES6. Sebastian On 10 September 2014 08:12, L2L 2L emanuelal...@hotmail.com wrote: This These feature--most of them-- would be something I see in the browser api... This is truly looking like w3c working group... ... But I don't see any chance of my words changing the direction of the spec Especially when you consider the original designer of the language steering this course... So in term, if you can't beat them, change them, might as well aid them --in what I feel to be In truth, the destruction of the original syntax, by the original creature of the language... Kinda wish they had a flag for these new syntax to be set... At least than, those who are toward the originally syntax style, would feel some sort of preservation for it-- In their quest to farther add on to ES as a --application-- language. --as duo to a private email by /be. This to me is not trolling, I'm responding to this person who respond two times to my post... So in terms, I should not have to worry about being banned from the mailing list cause of this message. E-S4L N-S4L On Sep 10, 2014, at 1:17 AM, Axel Rauschmayer a...@rauschma.de wrote: Now is second half of 2014, and lots of issues are not closed yet, from what I see. The spec already looks pretty complete to me and Traceur and TypeScript do a pretty good job of letting you use ES6 today. As previously announced here, the current schedule is to be finished by the end of the year, to start the publication process in March 2014 and to have a standard by June 2014. I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: It has already changed, but not for ES6. ECMAScript 7 and later will have fixed release dates. Only features that are ready at a given date will be included. Background: https://github.com/tc39/ecma262 -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
Meant this message is so uninformed that On Sep 10, 2014 6:55 AM, Mark S. Miller erig...@google.com wrote: Hi L2L, this message is uninformed that I must ask you to move to another forum, until you learn a lot more about js and web programming. This is not the place. On Sep 10, 2014 6:47 AM, L2L 2L emanuelal...@hotmail.com wrote: Yeah I guess I'm pretty late for that huh... No this is great, the more feature, the better. A lot of these feature would cause certain application not to be needed... In other words, use more of the language and less libraries Why you at it, how about reviving E4X? That way, we can lose the DOM api. After all, if ES was made for the web, than there should be method to access the DOM. It could be an object, like how the E4X was, but better. On another note, this is now becoming the mini-type application/JavaScript, than text/JavaScript. But consider the E4X though. E-S4L N-S4L On Sep 10, 2014, at 9:35 AM, Sebastian Zartner sebastianzart...@gmail.com wrote: I don't see why you're complaining. If you don't like the features in ES6, then just don't use them. The features of ES5 are still available. If you want to have more strict code, then add a use strict; statement to your code. And if you're against adding more features to the core language, then you should have complained several years ago at the planning of ES6. Sebastian On 10 September 2014 08:12, L2L 2L emanuelal...@hotmail.com wrote: This These feature--most of them-- would be something I see in the browser api... This is truly looking like w3c working group... ... But I don't see any chance of my words changing the direction of the spec Especially when you consider the original designer of the language steering this course... So in term, if you can't beat them, change them, might as well aid them --in what I feel to be In truth, the destruction of the original syntax, by the original creature of the language... Kinda wish they had a flag for these new syntax to be set... At least than, those who are toward the originally syntax style, would feel some sort of preservation for it-- In their quest to farther add on to ES as a --application-- language. --as duo to a private email by /be. This to me is not trolling, I'm responding to this person who respond two times to my post... So in terms, I should not have to worry about being banned from the mailing list cause of this message. E-S4L N-S4L On Sep 10, 2014, at 1:17 AM, Axel Rauschmayer a...@rauschma.de wrote: Now is second half of 2014, and lots of issues are not closed yet, from what I see. The spec already looks pretty complete to me and Traceur and TypeScript do a pretty good job of letting you use ES6 today. As previously announced here, the current schedule is to be finished by the end of the year, to start the publication process in March 2014 and to have a standard by June 2014. I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: It has already changed, but not for ES6. ECMAScript 7 and later will have fixed release dates. Only features that are ready at a given date will be included. Background: https://github.com/tc39/ecma262 -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
Axel Rauschmayer wrote: Now is second half of 2014, and lots of issues are not closed yet, from what I see. The spec already looks pretty complete to me and Traceur and TypeScript do a pretty good job of letting you use ES6 today. As previously announced here, the current schedule is to be finished by the end of the year, to start the publication process in March 2014 and to have a standard by June 2014. They already happened. Did you mean 2015? I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: It has already changed, but not for ES6. ECMAScript 7 and later will have fixed release dates. Only features that are ready at a given date will be included. Hallelujah! Background: https://github.com/tc39/ecma262 -- Dr. Axel Rauschmayer a...@rauschma.de mailto:a...@rauschma.de rauschma.de Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
As previously announced here, the current schedule is to be finished by the end of the year, to start the publication process in March 2014 and to have a standard by June 2014. They already happened. Did you mean 2015? Yes I did! -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: ... A community is writing the spec...
This L2L2L2 person has been trolling JS channels on freenode for the last few days, suggest ignoring them. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: ... A community is writing the spec...
I actually started believing @horse_esdiscuss left twitter to rant freely in here ... although I'm having hard time judging if there's simply a huge language barrier that might make it easy to misunderstand tone and intent. Emanuel I hope you are OK with answers you got also because there's not much else to say or do here. Regards On Wed, Sep 10, 2014 at 4:35 PM, Charles Pick char...@codemix.com wrote: This L2L2L2 person has been trolling JS channels on freenode for the last few days, suggest ignoring them. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
I was trying to... Leave it alone. But I'm seeing people speak on it and most importantly of me :-(. For those who speak ugly toward me, you don't have to speak at all. Abs for the rest... The two people who seem to be against this, and who are running this spec have spoken So there is no reason to keep speaking on something, that will never happen. E-S4L N-S4L On Sep 10, 2014, at 11:43 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I actually started believing @horse_esdiscuss left twitter to rant freely in here ... although I'm having hard time judging if there's simply a huge language barrier that might make it easy to misunderstand tone and intent. Emanuel I hope you are OK with answers you got also because there's not much else to say or do here. Regards On Wed, Sep 10, 2014 at 4:35 PM, Charles Pick char...@codemix.com wrote: This L2L2L2 person has been trolling JS channels on freenode for the last few days, suggest ignoring them. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
On Wed, Sep 10, 2014 at 8:17 AM, Alexandre Morgaut alexandre.morg...@4d.com
wrote:
Hi,
The way this discussion started looked very troll oriented, but let
comment few things I more or less agree or not with
What I see is more functionality of the browser api then an actually
language.
I actually work for 4D that provide JavaScript on the server in its
Wakanda Server which is not using node.js (at least for now)
I have to disagree with this statement as I see very good added value in
ES6 for our developers on server-side
And I look into node promise and the spec promise on MDN... And I'm still
not seeing the big picture. Could you give me a brief in your own words
I think the first place I saw Promise as a specification for JavaScript
was on the CommonJS mailing list and wiki
http://wiki.commonjs.org/wiki/Promises
Then on WHATWG, first called Future (not anymore online) and via this
github repository
https://github.com/slightlyoff/Promises/tree/master/historical_interest
Then in W3C drafts
http://www.w3.org/TR/2013/WD-dom-20131107/#promises
http://heycam.github.io/webidl/#idl-promise
Before finally going into JS core, then in ECMAScript
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects
An interesting blog post about Promise history in JS:
https://infrequently.org/2013/06/sfuturepromiseg/
It intends to make life better when chaining async callback calls which is
absolutely not browser specific
It may have stay as a library, but then no Specification call rely on it,
and many actually upcoming HTML5 features choose to rely on it
And this stupid ()={} arrow function... After seeing this I got the ideal
of letting functions follow the same rules as for, if, while... That if
it's one line of code, than let it be:
function add(arg0) console.log(arg++);
With out a body --curly braces--... Funny thing is that Firefox allow this
syntax style.
var arr = [];
[0,1,2,3].forEach(function(arg0)arr.push(100+arg0));
arr;
Copy paste in Firefox to see.
I'm not big fan neither of fat arrow functions because:
- the code looks less expressive to me, code becomes very cryptic for
anyone that don't know them and confusing as potentially associated to
+=, *=, ...
There is nothing ambiguous about `=` with regard to existing compound
assignment operators.
- they have no room for a function name that would be useful in debugger
stacks and closure scope names, or profilers function call counts
Still beware those are not only about syntax but also have different
behaviors. The binding of this is different
I admit I fear more confusion when I see people choosing the Array
forEach() to show an example
By default this in the forEach callback is bound to its second
parameter, so some developers may have some surprises
No, the default `this` in forEach is undefined. An explicit `thisArg` can
be provided as a second arg. In the most common case, fat arrow simplifies.
items.forEach(function(item, i) {
this[i] = doSomeComputingOnItem(item);
}, this);
// with or without the braces, it doesn't matter.
items.forEach((item, i) = {
this[i] = doSomeComputingOnItem(item);
});
Any attempt to do:
// with or without the braces, it doesn't matter.
items.forEach((item, i) = {
this[i] = doSomeComputingOnItem(item);
}, this);
Will just work because it means the same thing (even though the explicit
`thisArg` is just ignored).
But mistakes like the following will be discovered very quickly and it's a
mistake developers will likely only make once (if ever).
// with or without the braces, it doesn't matter.
items.forEach((item, i) = {
this[i] = doSomeComputingOnItem(item);
}, someOtherObject);
And the generator function... Couldn't it have been: generator(args){
yield args += gen;
console.log(args);
}
Plus with a constructor:
new Generator();
This is a little different story
Using non reserved keywords will for sure break some existing code
But of course another more explicit option could have been to provide a
new method on the Function native object
ex: Function.generator()
What exactly does that do? If it's just a regular function, then how could
`yield` have been safely made into a keyword within the body?
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
with all due respect Rick, and you know we've been talking about this
already, your forEach = example assumes you have created a subclassed
Array ... which trust me, it's the least common case you gonna have in the
real world 'cause basically impossible before ES6.
Everybody else that used to pass a different context to do something more
meaningful would fall in that trap at least once.
Of course they will learn their mistakes ... but please don't use forEach
as example about how cool is fat arrow 'cause in my opinion, with Array
extras, that's actually a perfect place where fat arrows is the most
confusing.
Regards
On Wed, Sep 10, 2014 at 6:58 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Sep 10, 2014 at 8:17 AM, Alexandre Morgaut
alexandre.morg...@4d.com wrote:
Hi,
The way this discussion started looked very troll oriented, but let
comment few things I more or less agree or not with
What I see is more functionality of the browser api then an actually
language.
I actually work for 4D that provide JavaScript on the server in its
Wakanda Server which is not using node.js (at least for now)
I have to disagree with this statement as I see very good added value in
ES6 for our developers on server-side
And I look into node promise and the spec promise on MDN... And I'm still
not seeing the big picture. Could you give me a brief in your own words
I think the first place I saw Promise as a specification for JavaScript
was on the CommonJS mailing list and wiki
http://wiki.commonjs.org/wiki/Promises
Then on WHATWG, first called Future (not anymore online) and via this
github repository
https://github.com/slightlyoff/Promises/tree/master/historical_interest
Then in W3C drafts
http://www.w3.org/TR/2013/WD-dom-20131107/#promises
http://heycam.github.io/webidl/#idl-promise
Before finally going into JS core, then in ECMAScript
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects
An interesting blog post about Promise history in JS:
https://infrequently.org/2013/06/sfuturepromiseg/
It intends to make life better when chaining async callback calls which
is absolutely not browser specific
It may have stay as a library, but then no Specification call rely on it,
and many actually upcoming HTML5 features choose to rely on it
And this stupid ()={} arrow function... After seeing this I got the
ideal of letting functions follow the same rules as for, if, while... That
if it's one line of code, than let it be:
function add(arg0) console.log(arg++);
With out a body --curly braces--... Funny thing is that Firefox allow
this syntax style.
var arr = [];
[0,1,2,3].forEach(function(arg0)arr.push(100+arg0));
arr;
Copy paste in Firefox to see.
I'm not big fan neither of fat arrow functions because:
- the code looks less expressive to me, code becomes very cryptic for
anyone that don't know them and confusing as potentially associated to
+=, *=, ...
There is nothing ambiguous about `=` with regard to existing compound
assignment operators.
- they have no room for a function name that would be useful in debugger
stacks and closure scope names, or profilers function call counts
Still beware those are not only about syntax but also have different
behaviors. The binding of this is different
I admit I fear more confusion when I see people choosing the Array
forEach() to show an example
By default this in the forEach callback is bound to its second
parameter, so some developers may have some surprises
No, the default `this` in forEach is undefined. An explicit `thisArg` can
be provided as a second arg. In the most common case, fat arrow simplifies.
items.forEach(function(item, i) {
this[i] = doSomeComputingOnItem(item);
}, this);
// with or without the braces, it doesn't matter.
items.forEach((item, i) = {
this[i] = doSomeComputingOnItem(item);
});
Any attempt to do:
// with or without the braces, it doesn't matter.
items.forEach((item, i) = {
this[i] = doSomeComputingOnItem(item);
}, this);
Will just work because it means the same thing (even though the explicit
`thisArg` is just ignored).
But mistakes like the following will be discovered very quickly and it's a
mistake developers will likely only make once (if ever).
// with or without the braces, it doesn't matter.
items.forEach((item, i) = {
this[i] = doSomeComputingOnItem(item);
}, someOtherObject);
And the generator function... Couldn't it have been: generator(args){
yield args += gen;
console.log(args);
}
Plus with a constructor:
new Generator();
This is a little different story
Using non reserved keywords will for sure break some existing code
But of course another more explicit option could have been to provide a
new method on the Function native object
ex: Function.generator()
What exactly does that do? If it's just a regular function, then how could
Re: ... A community is writing the spec...
On Wed, Sep 10, 2014 at 4:14 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
with all due respect Rick, and you know we've been talking about this
already, your forEach = example assumes you have created a subclassed
Array ... which trust me, it's the least common case you gonna have in the
real world 'cause basically impossible before ES6.
An implementation detail, don't nitpick.
// Call a method of this object or class or whatever to make Andrea happy
with my example
var happies = sads.map(sad = this.makeAndreaHappy(sad));
That work for you?
Everybody else that used to pass a different context to do something more
meaningful would fall in that trap at least once.
Of course they will learn their mistakes ... but please don't use
forEach as example about how cool is fat arrow 'cause in my opinion, with
Array extras, that's actually a perfect place where fat arrows is the most
confusing.
Regards
On Wed, Sep 10, 2014 at 6:58 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Wed, Sep 10, 2014 at 8:17 AM, Alexandre Morgaut
alexandre.morg...@4d.com wrote:
Hi,
The way this discussion started looked very troll oriented, but let
comment few things I more or less agree or not with
What I see is more functionality of the browser api then an actually
language.
I actually work for 4D that provide JavaScript on the server in its
Wakanda Server which is not using node.js (at least for now)
I have to disagree with this statement as I see very good added value in
ES6 for our developers on server-side
And I look into node promise and the spec promise on MDN... And I'm
still not seeing the big picture. Could you give me a brief in your own
words
I think the first place I saw Promise as a specification for JavaScript
was on the CommonJS mailing list and wiki
http://wiki.commonjs.org/wiki/Promises
Then on WHATWG, first called Future (not anymore online) and via this
github repository
https://github.com/slightlyoff/Promises/tree/master/historical_interest
Then in W3C drafts
http://www.w3.org/TR/2013/WD-dom-20131107/#promises
http://heycam.github.io/webidl/#idl-promise
Before finally going into JS core, then in ECMAScript
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects
An interesting blog post about Promise history in JS:
https://infrequently.org/2013/06/sfuturepromiseg/
It intends to make life better when chaining async callback calls which
is absolutely not browser specific
It may have stay as a library, but then no Specification call rely on
it, and many actually upcoming HTML5 features choose to rely on it
And this stupid ()={} arrow function... After seeing this I got the
ideal of letting functions follow the same rules as for, if, while... That
if it's one line of code, than let it be:
function add(arg0) console.log(arg++);
With out a body --curly braces--... Funny thing is that Firefox allow
this syntax style.
var arr = [];
[0,1,2,3].forEach(function(arg0)arr.push(100+arg0));
arr;
Copy paste in Firefox to see.
I'm not big fan neither of fat arrow functions because:
- the code looks less expressive to me, code becomes very cryptic for
anyone that don't know them and confusing as potentially associated to
+=, *=, ...
There is nothing ambiguous about `=` with regard to existing compound
assignment operators.
- they have no room for a function name that would be useful in debugger
stacks and closure scope names, or profilers function call counts
Still beware those are not only about syntax but also have different
behaviors. The binding of this is different
I admit I fear more confusion when I see people choosing the Array
forEach() to show an example
By default this in the forEach callback is bound to its second
parameter, so some developers may have some surprises
No, the default `this` in forEach is undefined. An explicit `thisArg` can
be provided as a second arg. In the most common case, fat arrow simplifies.
items.forEach(function(item, i) {
this[i] = doSomeComputingOnItem(item);
}, this);
// with or without the braces, it doesn't matter.
items.forEach((item, i) = {
this[i] = doSomeComputingOnItem(item);
});
Any attempt to do:
// with or without the braces, it doesn't matter.
items.forEach((item, i) = {
this[i] = doSomeComputingOnItem(item);
}, this);
Will just work because it means the same thing (even though the explicit
`thisArg` is just ignored).
But mistakes like the following will be discovered very quickly and it's
a mistake developers will likely only make once (if ever).
// with or without the braces, it doesn't matter.
items.forEach((item, i) = {
this[i] = doSomeComputingOnItem(item);
}, someOtherObject);
And the generator function... Couldn't it have been: generator(args){
yield args += gen;
console.log(args);
}
Plus with a constructor:
new Generator();
This
Re: ... A community is writing the spec...
assumes you have created a subclassed Array ... which trust me, it's the least common case you gonna have in the real world I've been subclassing arrays in at least two separate projects, and it is very much possible via prototype injection. You (almost) can't intercept direct arr[x] calls, but other than that everything should work fine. Everybody else that used to pass a different context to do something more meaningful Does anyone really do that? Except for fine-tuning performance? As far as I remember, people either use closures or .bind() stuff. 11.09.2014, 03:14, "Andrea Giammarchi" andrea.giammar...@gmail.com:with all due respect Rick, and you know we've been talking about this already, your forEach = example assumes you have created a subclassed Array ... which trust me, it's the least common case you gonna have in the real world 'cause basically impossible before ES6. Everybody else that used to pass a different context to do something more meaningful would fall in that trap at least once. Of course they will learn "their" mistakes ... but please don't use forEach as example about how cool is fat arrow 'cause in my opinion, with Array extras, that's actually a perfect place where fat arrows is the most confusing. RegardsOn Wed, Sep 10, 2014 at 6:58 PM, Rick Waldron waldron.r...@gmail.com wrote:On Wed, Sep 10, 2014 at 8:17 AM, Alexandre Morgaut alexandre.morg...@4d.com wrote:Hi, The way this discussion started looked very troll oriented, but let comment few things I more or less agree or not withWhat I see is more functionality of the browser api then an actually language. I actually work for 4D that provide _javascript_ on the server in its Wakanda Server which is not using node.js (at least for now)I have to disagree with this statement as I see very good added value in ES6 for our developers on server-sideAnd I look into node promise and the spec promise on MDN... And I'm still not seeing the big picture. Could you give me a brief in your own words I think the first place I saw Promise as a specification for _javascript_ was on the CommonJS mailing list and wikihttp://wiki.commonjs.org/wiki/Promises Then on WHATWG, first called Future (not anymore online) and via this github repositoryhttps://github.com/slightlyoff/Promises/tree/master/historical_interest Then in W3C draftshttp://www.w3.org/TR/2013/WD-dom-20131107/#promiseshttp://heycam.github.io/webidl/#idl-promise Before finally going into JS core, then in ECMAScripthttp://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects An interesting blog post about Promise history in JS:https://infrequently.org/2013/06/sfuturepromiseg/ It intends to make life better when chaining async callback calls which is absolutely not browser specificIt may have stay as a library, but then no Specification call rely on it, and many actually upcoming HTML5 features choose to rely on itAnd this stupid ()={} arrow function... After seeing this I got the ideal of letting functions follow the same rules as for, if, while... That if it's one line of code, than let it be: function add(arg0) console.log(arg++); With out a body --curly braces--... Funny thing is that Firefox allow this syntax style. var arr = [];[0,1,2,3].forEach(function(arg0)arr.push(100+arg0));arr; Copy paste in Firefox to see. I'm not big fan neither of fat arrow functions because:- the code looks less expressive to me, code becomes very cryptic for anyone that don't know them and confusing as potentially associated to "+=", "*=", ... There is nothing ambiguous about `=` with regard to existing compound assignment operators. - they have no room for a function name that would be useful in debugger stacks and closure scope names, or profilers function call counts Still beware those are not only about syntax but also have different behaviors. The binding of "this" is differentI admit I fear more confusion when I see people choosing the Array forEach() to show an exampleBy default "this" in the forEach callback is bound to its second parameter, so some developers may have some surprises No, the default `this` in forEach is undefined. An explicit `thisArg` can be provided as a second arg. In the most common case, fat arrow simplifies. items.forEach(function(item, i) { this[i] = doSomeComputingOnItem(item); }, this); // with or without the braces, it doesn't matter. items.forEach((item, i) = { this[i] = doSomeComputingOnItem(item); }); Any attempt to do: // with or without the braces, it doesn't matter. items.forEach((item, i) = { this[i] = doSomeComputingOnItem(item); }, this); Will just work because it means the same thing (even though the explicit `thisArg` is just ignored). But mistakes like the following will be discovered very quickly and it's a mistake developers will likely only make once (if ever). // with or without the braces, it doesn't matter. items.forEach((item, i) = { this[i] = doSomeComputingOnItem(item); },
Re: {Spam?} Re: ... A community is writing the spec...
Alex Kocharin wrote: Everybody else that used to pass a different context to do something more meaningful Does anyone really do that? Except for fine-tuning performance? As far as I remember, people either use closures or .bind() stuff. Yup. Andrea, if you want - (which you do) can you kindly stop complaining that = is not -? That's like saying blue cheese is bad because it isn't cheddar. Both are great! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
I disagree, Although I don't comment here, I do follow the discussion and I have been working with --harmony on Node.js for a while now. The path seems to be going in the right direction. The things that reach implementation status tend to help, I have found lot's of features very constructive. Languages tend to evolve, that's how it is. Francisco On Tue, Sep 9, 2014 at 10:54 AM, L2L 2L emanuelal...@hotmail.com wrote: It worry me... That a community is writing the spec... That a community is writing the spec Look like W3C... That everyone is striving to get what they want in the language. Most of us are ES5 developers Meaning we don't delve into ES6 and what else to come. let, const, and a couple of others spec implantation is okay. These help better the language... But your adding feature and no trying to better what's already there. You might as well call yourself W3C equivalent.E As long as one can write compliant ES5. A new more stricture spec/style is being made. It's call ES5+ meaning that all compliant code is to be writing in ES5 and additional add on as the let and const statement plus other +. What I see is more functionality of the browser api then an actually language. A lot of us hope this spec die, as did ES4. Most of what you're adding could have been another add on spec... Like commonjs add on. Have fun destroying a language. ES5+4Life E-S4L ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
But What of Node? What are they planing to do to her?
Developers are cry babies!
I don't mind the spaghetti mountain... Don't think I won't progress my
learning... I'm just saying that if that what I have to do to make it do what I
need for it to do... Than I'll do it.
And I look into node promise and the spec promise on MDN... And I'm still not
seeing the big picture. Could you give me a brief in your own words
And this stupid ()={} arrow function... After seeing this I got the ideal of
letting functions follow the same rules as for, if, while... That if it's one
line of code, than let it be:
function add(arg0) console.log(arg++);
With out a body --curly braces--... Funny thing is that Firefox allow this
syntax style.
var arr = [];
[0,1,2,3].forEach(function(arg0)arr.push(100+arg0));
arr;
Copy paste in Firefox to see.
And the generator function... Couldn't it have been: generator(args){
yield args += gen;
console.log(args);
}
Plus with a constructor:
new Generator();
Just saying What's happening to Node?
E-S4L
N-S4L
On Sep 9, 2014, at 6:03 AM, Francisco Ferreira
francisco.m.s.ferre...@gmail.com wrote:
ES6 is backwards compatible, you don't need to use the new features if you
don't want to.
On Tue, Sep 9, 2014 at 11:01 AM, L2L 2L emanuelal...@hotmail.com wrote:
Francisco Is the developers of Node... Are they going to force us to use
ES6 syntax in newer version of Node?
There are a group of us who truly wish to stay ES5 with the additional add
on as said: ES5+.
... So are they?
E-S4L
N-S4L
On Sep 9, 2014, at 5:58 AM, Francisco Ferreira
francisco.m.s.ferre...@gmail.com wrote:
I disagree,
Although I don't comment here, I do follow the discussion and I have been
working with --harmony on Node.js for a while now. The path seems to be
going in the right direction. The things that reach implementation status
tend to help, I have found lot's of features very constructive.
Languages tend to evolve, that's how it is.
Francisco
On Tue, Sep 9, 2014 at 10:54 AM, L2L 2L emanuelal...@hotmail.com wrote:
It worry me... That a community is writing the spec... That a community is
writing the spec Look like W3C... That everyone is striving to get
what they want in the language.
Most of us are ES5 developers Meaning we don't delve into ES6 and what
else to come.
let, const, and a couple of others spec implantation is okay. These help
better the language... But your adding feature and no trying to better
what's already there.
You might as well call yourself W3C equivalent.E
As long as one can write compliant ES5.
A new more stricture spec/style is being made. It's call ES5+ meaning that
all compliant code is to be writing in ES5 and additional add on as the
let and const statement plus other +.
What I see is more functionality of the browser api then an actually
language. A lot of us hope this spec die, as did ES4.
Most of what you're adding could have been another add on spec... Like
commonjs add on.
Have fun destroying a language.
ES5+4Life
E-S4L
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
... This language is turning note in an application than a programming language. It could of been a commonjs thing... Long live ES5+. I like the let, and const syntax add on. Foo feature and fits into the language. Yes ai agree they should release as CSS is releasing. E-S4L N-S4L On Sep 9, 2014, at 6:36 AM, Herby Vojčík he...@mailbox.sk wrote: L2L 2L wrote: It worry me... That a community is writing the spec... That a community Well, not the community is writing the spec. AWB is. :-) And he can be pretty tough, I more or less stopped reading this list thoroughly after his letting one of the issues I saw as important left ignored. Nevertheless: is writing the spec Look like W3C... That everyone is striving to get what they want in the language. Most of us are ES5 developers Meaning we don't delve into ES6 and what else to come. let, const, and a couple of others spec implantation is okay. These help better the language... But your adding feature and no trying to better what's already there. You might as well call yourself W3C equivalent.E As long as one can write compliant ES5. A new more stricture spec/style is being made. It's call ES5+ meaning that all compliant code is to be writing in ES5 and additional add on as the let and const statement plus other +. What I see is more functionality of the browser api then an actually language. A lot of us hope this spec die, as did ES4. Most of what you're adding could have been another add on spec... Like commonjs add on. I liked the idea of ES6 pretty much. The commitee was pretty strict in not adding too much, mostly paving cowpaths, had some roadmap, according to which ES6 should be approved in end of 2013. Now is second half of 2014, and lots of issues are not closed yet, from what I see. I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: - More frequent, albeit smaller, releases are embraced as a rule; - ES5.5 will be scheduled (and delivered) as a Christmas present in 2014, selecting only small subset of less controversial items (let, const, Reflect global object with all API applicable to ES5.5, possibly block scope; no modules, no classes (unless there is consensus they are already near to perfect, though my issue was about new/super inconsistency), no symbols, no proxies, no for-of, iterators, generators, comprehensions, no promises); - schedule ES5.6 (and deliver it) for July 2015 with, for example, for-of, iterators, generators, comprehensions (it's all related, so in a single set) and if possible, classes and/or promises; ... etc. Possibly switching to 6 when something big gets in (symbols, classes, proxies). This would be nice. Really nice. To all of us who want to get ES.next and actually start developing in it. Thanks, Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
Is there seriously going to be no attempt whatsoever to moderate this list? On Tue, Sep 9, 2014 at 3:42 AM, L2L 2L emanuelal...@hotmail.com wrote: ... This language is turning note in an application than a programming language. It could of been a commonjs thing... Long live ES5+. I like the let, and const syntax add on. Foo feature and fits into the language. Yes ai agree they should release as CSS is releasing. E-S4L N-S4L On Sep 9, 2014, at 6:36 AM, Herby Vojčík he...@mailbox.sk wrote: L2L 2L wrote: It worry me... That a community is writing the spec... That a community Well, not the community is writing the spec. AWB is. :-) And he can be pretty tough, I more or less stopped reading this list thoroughly after his letting one of the issues I saw as important left ignored. Nevertheless: is writing the spec Look like W3C... That everyone is striving to get what they want in the language. Most of us are ES5 developers Meaning we don't delve into ES6 and what else to come. let, const, and a couple of others spec implantation is okay. These help better the language... But your adding feature and no trying to better what's already there. You might as well call yourself W3C equivalent.E As long as one can write compliant ES5. A new more stricture spec/style is being made. It's call ES5+ meaning that all compliant code is to be writing in ES5 and additional add on as the let and const statement plus other +. What I see is more functionality of the browser api then an actually language. A lot of us hope this spec die, as did ES4. Most of what you're adding could have been another add on spec... Like commonjs add on. I liked the idea of ES6 pretty much. The commitee was pretty strict in not adding too much, mostly paving cowpaths, had some roadmap, according to which ES6 should be approved in end of 2013. Now is second half of 2014, and lots of issues are not closed yet, from what I see. I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: - More frequent, albeit smaller, releases are embraced as a rule; - ES5.5 will be scheduled (and delivered) as a Christmas present in 2014, selecting only small subset of less controversial items (let, const, Reflect global object with all API applicable to ES5.5, possibly block scope; no modules, no classes (unless there is consensus they are already near to perfect, though my issue was about new/super inconsistency), no symbols, no proxies, no for-of, iterators, generators, comprehensions, no promises); - schedule ES5.6 (and deliver it) for July 2015 with, for example, for-of, iterators, generators, comprehensions (it's all related, so in a single set) and if possible, classes and/or promises; ... etc. Possibly switching to 6 when something big gets in (symbols, classes, proxies). This would be nice. Really nice. To all of us who want to get ES.next and actually start developing in it. Thanks, Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
Huh? ... Should I be doing so? ... Huh? E-S4L N-S4L On Sep 9, 2014, at 5:54 PM, Alex Russell slightly...@google.com wrote: Is there seriously going to be no attempt whatsoever to moderate this list? On Tue, Sep 9, 2014 at 3:42 AM, L2L 2L emanuelal...@hotmail.com wrote: ... This language is turning note in an application than a programming language. It could of been a commonjs thing... Long live ES5+. I like the let, and const syntax add on. Foo feature and fits into the language. Yes ai agree they should release as CSS is releasing. E-S4L N-S4L On Sep 9, 2014, at 6:36 AM, Herby Vojčík he...@mailbox.sk wrote: L2L 2L wrote: It worry me... That a community is writing the spec... That a community Well, not the community is writing the spec. AWB is. :-) And he can be pretty tough, I more or less stopped reading this list thoroughly after his letting one of the issues I saw as important left ignored. Nevertheless: is writing the spec Look like W3C... That everyone is striving to get what they want in the language. Most of us are ES5 developers Meaning we don't delve into ES6 and what else to come. let, const, and a couple of others spec implantation is okay. These help better the language... But your adding feature and no trying to better what's already there. You might as well call yourself W3C equivalent.E As long as one can write compliant ES5. A new more stricture spec/style is being made. It's call ES5+ meaning that all compliant code is to be writing in ES5 and additional add on as the let and const statement plus other +. What I see is more functionality of the browser api then an actually language. A lot of us hope this spec die, as did ES4. Most of what you're adding could have been another add on spec... Like commonjs add on. I liked the idea of ES6 pretty much. The commitee was pretty strict in not adding too much, mostly paving cowpaths, had some roadmap, according to which ES6 should be approved in end of 2013. Now is second half of 2014, and lots of issues are not closed yet, from what I see. I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: - More frequent, albeit smaller, releases are embraced as a rule; - ES5.5 will be scheduled (and delivered) as a Christmas present in 2014, selecting only small subset of less controversial items (let, const, Reflect global object with all API applicable to ES5.5, possibly block scope; no modules, no classes (unless there is consensus they are already near to perfect, though my issue was about new/super inconsistency), no symbols, no proxies, no for-of, iterators, generators, comprehensions, no promises); - schedule ES5.6 (and deliver it) for July 2015 with, for example, for-of, iterators, generators, comprehensions (it's all related, so in a single set) and if possible, classes and/or promises; ... etc. Possibly switching to 6 when something big gets in (symbols, classes, proxies). This would be nice. Really nice. To all of us who want to get ES.next and actually start developing in it. Thanks, Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
Anyone care to justify the use case for the proxy object? Yes I understand it'll let us defined the behavior of an object. But couldn't that be a method for the Object constructor? E-S4L N-S4L On Sep 9, 2014, at 5:55 PM, L2L 2L emanuelal...@hotmail.com wrote: Huh? ... Should I be doing so? ... Huh? E-S4L N-S4L On Sep 9, 2014, at 5:54 PM, Alex Russell slightly...@google.com wrote: Is there seriously going to be no attempt whatsoever to moderate this list? On Tue, Sep 9, 2014 at 3:42 AM, L2L 2L emanuelal...@hotmail.com wrote: ... This language is turning note in an application than a programming language. It could of been a commonjs thing... Long live ES5+. I like the let, and const syntax add on. Foo feature and fits into the language. Yes ai agree they should release as CSS is releasing. E-S4L N-S4L On Sep 9, 2014, at 6:36 AM, Herby Vojčík he...@mailbox.sk wrote: L2L 2L wrote: It worry me... That a community is writing the spec... That a community Well, not the community is writing the spec. AWB is. :-) And he can be pretty tough, I more or less stopped reading this list thoroughly after his letting one of the issues I saw as important left ignored. Nevertheless: is writing the spec Look like W3C... That everyone is striving to get what they want in the language. Most of us are ES5 developers Meaning we don't delve into ES6 and what else to come. let, const, and a couple of others spec implantation is okay. These help better the language... But your adding feature and no trying to better what's already there. You might as well call yourself W3C equivalent.E As long as one can write compliant ES5. A new more stricture spec/style is being made. It's call ES5+ meaning that all compliant code is to be writing in ES5 and additional add on as the let and const statement plus other +. What I see is more functionality of the browser api then an actually language. A lot of us hope this spec die, as did ES4. Most of what you're adding could have been another add on spec... Like commonjs add on. I liked the idea of ES6 pretty much. The commitee was pretty strict in not adding too much, mostly paving cowpaths, had some roadmap, according to which ES6 should be approved in end of 2013. Now is second half of 2014, and lots of issues are not closed yet, from what I see. I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: - More frequent, albeit smaller, releases are embraced as a rule; - ES5.5 will be scheduled (and delivered) as a Christmas present in 2014, selecting only small subset of less controversial items (let, const, Reflect global object with all API applicable to ES5.5, possibly block scope; no modules, no classes (unless there is consensus they are already near to perfect, though my issue was about new/super inconsistency), no symbols, no proxies, no for-of, iterators, generators, comprehensions, no promises); - schedule ES5.6 (and deliver it) for July 2015 with, for example, for-of, iterators, generators, comprehensions (it's all related, so in a single set) and if possible, classes and/or promises; ... etc. Possibly switching to 6 when something big gets in (symbols, classes, proxies). This would be nice. Really nice. To all of us who want to get ES.next and actually start developing in it. Thanks, Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ... A community is writing the spec...
You can find lots of information about design discussions by reading the ecmascript wiki, for example: http://wiki.ecmascript.org/doku.php?id=harmony:proxies. The other good resource is the past posts to this list and the meeting minutes, http://esdiscuss.org/. In general, the content that is painstakingly written down in the ES6 specification has been designed and discussed in great detail. The appropriate level of comments on those features needs to be equally detailed and thoughtful. Random comments about how you personally don't like some aspects of the design are better directed to your followers on twitter or perhaps a blog post. And of course you are free not to use any new features you dislike. I believe that is what Alex was attempting to communicate. jjb On Tue, Sep 9, 2014 at 3:25 PM, L2L 2L emanuelal...@hotmail.com wrote: Anyone care to justify the use case for the proxy object? Yes I understand it'll let us defined the behavior of an object. But couldn't that be a method for the Object constructor? E-S4L N-S4L On Sep 9, 2014, at 5:55 PM, L2L 2L emanuelal...@hotmail.com wrote: Huh? ... Should I be doing so? ... Huh? E-S4L N-S4L On Sep 9, 2014, at 5:54 PM, Alex Russell slightly...@google.com wrote: Is there seriously going to be no attempt whatsoever to moderate this list? On Tue, Sep 9, 2014 at 3:42 AM, L2L 2L emanuelal...@hotmail.com wrote: ... This language is turning note in an application than a programming language. It could of been a commonjs thing... Long live ES5+. I like the let, and const syntax add on. Foo feature and fits into the language. Yes ai agree they should release as CSS is releasing. E-S4L N-S4L On Sep 9, 2014, at 6:36 AM, Herby Vojčík he...@mailbox.sk wrote: L2L 2L wrote: It worry me... That a community is writing the spec... That a community Well, not the community is writing the spec. AWB is. :-) And he can be pretty tough, I more or less stopped reading this list thoroughly after his letting one of the issues I saw as important left ignored. Nevertheless: is writing the spec Look like W3C... That everyone is striving to get what they want in the language. Most of us are ES5 developers Meaning we don't delve into ES6 and what else to come. let, const, and a couple of others spec implantation is okay. These help better the language... But your adding feature and no trying to better what's already there. You might as well call yourself W3C equivalent.E As long as one can write compliant ES5. A new more stricture spec/style is being made. It's call ES5+ meaning that all compliant code is to be writing in ES5 and additional add on as the let and const statement plus other +. What I see is more functionality of the browser api then an actually language. A lot of us hope this spec die, as did ES4. Most of what you're adding could have been another add on spec... Like commonjs add on. I liked the idea of ES6 pretty much. The commitee was pretty strict in not adding too much, mostly paving cowpaths, had some roadmap, according to which ES6 should be approved in end of 2013. Now is second half of 2014, and lots of issues are not closed yet, from what I see. I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: - More frequent, albeit smaller, releases are embraced as a rule; - ES5.5 will be scheduled (and delivered) as a Christmas present in 2014, selecting only small subset of less controversial items (let, const, Reflect global object with all API applicable to ES5.5, possibly block scope; no modules, no classes (unless there is consensus they are already near to perfect, though my issue was about new/super inconsistency), no symbols, no proxies, no for-of, iterators, generators, comprehensions, no promises); - schedule ES5.6 (and deliver it) for July 2015 with, for example, for-of, iterators, generators, comprehensions (it's all related, so in a single set) and if possible, classes and/or promises; ... etc. Possibly switching to 6 when something big gets in (symbols, classes, proxies). This would be nice. Really nice. To all of us who want to get ES.next and actually start developing in it. Thanks, Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss
Re: ... A community is writing the spec...
Thank you Did why didn't he say so instead of crying out to a mod? Are you a mod? E-S4L N-S4L On Sep 9, 2014, at 6:47 PM, John Barton johnjbar...@google.com wrote: You can find lots of information about design discussions by reading the ecmascript wiki, for example: http://wiki.ecmascript.org/doku.php?id=harmony:proxies. The other good resource is the past posts to this list and the meeting minutes, http://esdiscuss.org/. In general, the content that is painstakingly written down in the ES6 specification has been designed and discussed in great detail. The appropriate level of comments on those features needs to be equally detailed and thoughtful. Random comments about how you personally don't like some aspects of the design are better directed to your followers on twitter or perhaps a blog post. And of course you are free not to use any new features you dislike. I believe that is what Alex was attempting to communicate. jjb On Tue, Sep 9, 2014 at 3:25 PM, L2L 2L emanuelal...@hotmail.com wrote: Anyone care to justify the use case for the proxy object? Yes I understand it'll let us defined the behavior of an object. But couldn't that be a method for the Object constructor? E-S4L N-S4L On Sep 9, 2014, at 5:55 PM, L2L 2L emanuelal...@hotmail.com wrote: Huh? ... Should I be doing so? ... Huh? E-S4L N-S4L On Sep 9, 2014, at 5:54 PM, Alex Russell slightly...@google.com wrote: Is there seriously going to be no attempt whatsoever to moderate this list? On Tue, Sep 9, 2014 at 3:42 AM, L2L 2L emanuelal...@hotmail.com wrote: ... This language is turning note in an application than a programming language. It could of been a commonjs thing... Long live ES5+. I like the let, and const syntax add on. Foo feature and fits into the language. Yes ai agree they should release as CSS is releasing. E-S4L N-S4L On Sep 9, 2014, at 6:36 AM, Herby Vojčík he...@mailbox.sk wrote: L2L 2L wrote: It worry me... That a community is writing the spec... That a community Well, not the community is writing the spec. AWB is. :-) And he can be pretty tough, I more or less stopped reading this list thoroughly after his letting one of the issues I saw as important left ignored. Nevertheless: is writing the spec Look like W3C... That everyone is striving to get what they want in the language. Most of us are ES5 developers Meaning we don't delve into ES6 and what else to come. let, const, and a couple of others spec implantation is okay. These help better the language... But your adding feature and no trying to better what's already there. You might as well call yourself W3C equivalent.E As long as one can write compliant ES5. A new more stricture spec/style is being made. It's call ES5+ meaning that all compliant code is to be writing in ES5 and additional add on as the let and const statement plus other +. What I see is more functionality of the browser api then an actually language. A lot of us hope this spec die, as did ES4. Most of what you're adding could have been another add on spec... Like commonjs add on. I liked the idea of ES6 pretty much. The commitee was pretty strict in not adding too much, mostly paving cowpaths, had some roadmap, according to which ES6 should be approved in end of 2013. Now is second half of 2014, and lots of issues are not closed yet, from what I see. I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: - More frequent, albeit smaller, releases are embraced as a rule; - ES5.5 will be scheduled (and delivered) as a Christmas present in 2014, selecting only small subset of less controversial items (let, const, Reflect global object with all API applicable to ES5.5, possibly block scope; no modules, no classes (unless there is consensus they are already near to perfect, though my issue was about new/super inconsistency), no symbols, no proxies, no for-of, iterators, generators, comprehensions, no promises); - schedule ES5.6 (and deliver it) for July 2015 with, for example, for-of, iterators, generators, comprehensions (it's all related, so in a single set) and if possible, classes and/or promises; ... etc. Possibly switching to 6 when something big gets in (symbols, classes, proxies). This would be nice. Really nice. To all of us who want to get ES.next and actually start developing in it. Thanks, Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list
Re: ... A community is writing the spec...
Now is second half of 2014, and lots of issues are not closed yet, from what I see. The spec already looks pretty complete to me and Traceur and TypeScript do a pretty good job of letting you use ES6 today. As previously announced here, the current schedule is to be finished by the end of the year, to start the publication process in March 2014 and to have a standard by June 2014. I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: It has already changed, but not for ES6. ECMAScript 7 and later will have fixed release dates. Only features that are ready at a given date will be included. Background: https://github.com/tc39/ecma262 -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
