... 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
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
.... 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
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,
... 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
Is there seriously going to be no attempt whatsoever to moderate this list?
Huh? ... Should I be doing so? ... Huh?
E-S4L N
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
You can find lots of information about design discussions by reading the ecmascript wiki, for example: harmony:proxies. The other good resource is the past posts to this list and the meeting minutes, 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
Thank you.... Did why didn't he say so instead of crying out to a mod?
Are you a mod?
E-S4L N
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: tc39/ecma262
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
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
.... 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
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.
Meant "this message is so uninformed that...".
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!
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!
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 wiki.commonjs.org/wiki/Promises
Then on WHATWG, first called Future (not anymore online) and via this github repository slightlyoff/Promises/tree/master/historical_interest
Then in W3C drafts www.w3.org/TR/2013/WD-dom-20131107/#promises, heycam.github.io/webidl/#idl-promise
Before finally going into JS core, then in ECMAScript people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects
An interesting blog post about Promise history in JS: 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 "+=", "*=", ...
- 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
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()
Anyone care to justify the use case for the proxy object?
Actually it's easy to justify with a very basic use case ES5 getter / setter are great on Object but not reasonably usable when trying to catch operations on Arrays elements (which is not at all browser specific)
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!
+1
That's all I felt necessary to say Hope it didn't pollute and maybe even could help the group
,
Alexandre
[cid:246c92.png at d4cdef0d.498b4256] Alexandre Morgaut Wakanda Community Manager Email : Alexandre.Morgaut at 4d.com<mailto:Alexandre.Morgaut at 4d.com>
Web : www.4D.comwww.4D.com
4D SAS 60, rue d'Alsace 92110 Clichy - France Standard : +33 1 40 87 92 00
[cid:ecce8b.png at 13230cc7.468344ee]www.4d.com/fr/company/events/summiteu2014.html
This L2L2L2 person has been trolling JS channels on freenode for the last few days, suggest ignoring them.
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.
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
On Wed, Sep 10, 2014 at 8:17 AM, Alexandre Morgaut <Alexandre.Morgaut at 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 wiki.commonjs.org/wiki/Promises
Then on WHATWG, first called Future (not anymore online) and via this github repository slightlyoff/Promises/tree/master/historical_interest
Then in W3C drafts www.w3.org/TR/2013/WD-dom-20131107/#promises, heycam.github.io/webidl/#idl-promise
Before finally going into JS core, then in ECMAScript people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects
An interesting blog post about Promise history in JS: 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?
E-S4L N-S4L
On Sep 10, 2014, at 11:17 AM, "Alexandre Morgaut" <Alexandre.Morgaut at 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 wiki.commonjs.org/wiki/Promises
Then on WHATWG, first called Future (not anymore online) and via this github repository slightlyoff/Promises/tree/master/historical_interest
Then in W3C drafts www.w3.org/TR/2013/WD-dom-20131107/#promises, heycam.github.io/webidl/#idl-promise
Before finally going into JS core, then in ECMAScript people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects
An interesting blog post about Promise history in JS: 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 "+=", "*=", ...
- they have no room for a function name that would be useful in debugger stacks and closure scope names, or profilers function call counts
Yes I agree with the arrow function ideal. It cN confuse the reader. Why add another way to defined a function? So people who are lazy don't have to write as much?
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
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()
I second this new method ideal. That way we can shake off the silly syntax of * for generator. Or as I said us the word generator() and Generator() as a new class.
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.
On Wed, Sep 10, 2014 at 4:14 PM, Andrea Giammarchi < andrea.giammarchi at 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?
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20140911/dcc245e5/attachment-0001
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
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20140911/f73bda1e/attachment-0001
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