... A community is writing the spec...

L2L 2L emanuelallen at hotmail.com
Wed Sep 10 11:12:54 PDT 2014



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
> 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 "+=",  "*=", ... 
> - 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.
> 
> 
> 
> 
>> 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
> 
> 
> Regards,
> 
> Alexandre
> <246c92.png>	
> Alexandre Morgaut
> Wakanda Community Manager
> Email :	Alexandre.Morgaut at 4d.com
> Web :	www.4D.com
> 4D SAS
> 60, rue d'Alsace
> 92110 Clichy - France
> Standard :	+33 1 40 87 92 00
> <ecce8b.png>
> 
>  
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140910/e23fa366/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 246c92.png
Type: image/png
Size: 4628 bytes
Desc: 246c92.png
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140910/e23fa366/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecce8b.png
Type: image/png
Size: 91073 bytes
Desc: ecce8b.png
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140910/e23fa366/attachment-0003.png>


More information about the es-discuss mailing list