Upcoming talk on ES6 in Russia

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Upcoming talk on ES6 in Russia

Axel Rauschmayer
On March 30, I’ll hold a talk on ECMAScript 6 at CodeFest 2013 in Novosibirsk [1] where I hope to convince people that they have something to look forward to.

A draft of my slides is here, feedback welcome:
http://dl.2ality.com/codefest_es6.pdf

[1] http://2013.codefest.ru/

-- 
Dr. Axel Rauschmayer

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming talk on ES6 in Russia

denom
Hello Dr. Rauschmayer,
 
Could you plase explain how the slide #23."Object literals" comes in alingment with slide #7."Challenges of evolving a web language" where it is written "Preserve nature of JavaScript" ?
 
The method definitions presenteed on #23 voided anything that JavaScript Object Notation stands for which I consider it is indeed a basic building block of JavaScript and no nature preserved here. A mixture of named fucntions, voidance of key/value pairs, and property values shorthand seems like a soup of a little bit of everything and a soup was never a good friend of maintenability of the code. This is monsterous.
 
I see lots of drafts and proposals tend to be from people used to write C(*)/Java or CoffeeScript which is adopted only by a small subset of JavaScript developers who are mainly Rubyists. The fact that some things seem to them as 'acceptable' doesn't mean that comfort with the JavaScript standards and conventions. JavaScript,like all other languages, is not a language to that fits to everyone.
 
Best regards,
Dimitris K.
 
------ Original Message ------
From: "Axel Rauschmayer" <[hidden email]>
To: "es-discuss list" <[hidden email]>
Sent: 3/23/2013 6:37:38 PM
Subject: Upcoming talk on ES6 in Russia
On March 30, I’ll hold a talk on ECMAScript 6 at CodeFest 2013 in Novosibirsk [1] where I hope to convince people that they have something to look forward to.

A draft of my slides is here, feedback welcome:
http://dl.2ality.com/codefest_es6.pdf


-- 
Dr. Axel Rauschmayer

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming talk on ES6 in Russia

Herby Vojčík
In reply to this post by Axel Rauschmayer
In slide "Classes: sub-type" use `super(x,y);` instead of overspecified `super.constructor(x,y);`.
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming talk on ES6 in Russia

Axel Rauschmayer
In reply to this post by denom
<base href="x-msg://18/">
Could you plase explain how the slide #23."Object literals" comes in alingment with slide #7."Challenges of evolving a web language" where it is written "Preserve nature of JavaScript" ?

There are two camps, each of which has strong feelings:

1. JavaScript is good enough as it is, don’t change anything, don’t ruin the language. [I’m writing this without irony.]
2. JavaScript needs to evolve. Quirks need to be cleaned up, features need to be supported directly by the language.

I don’t think either camp will ever completely convince the other one. Let me try, anyway; I consider myself (cautiously) in camp 2.

The method definitions presenteed on #23 voided anything that JavaScript Object Notation stands for which I consider it is indeed a basic building block of JavaScript and no nature preserved here.

Note: JSON has always been a subset of JavaScript: It doesn’t support properties whose values are functions, unquoted property keys, etc.

A mixture of named fucntions, voidance of key/value pairs, and property values shorthand seems like a soup of a little bit of everything and a soup was never a good friend of maintenability of the code. This is monsterous.

It is indeed a soup, it demonstrates all new features at once:

  let name = 'foo';
  let obj = {
      __proto__: SomeObject                 // special prop (1)
      myMethod(arg1, arg2) {           // method definition (2)
          super.myMethod(arg1, arg2);    // super reference (3)
      },
      [name]: 123,                 // computed property key (4)
      bar                       // property value shorthand (5)
  }

Let’s look at feature separately:

1. Rarely used, handy if you want to set up a prototype chain or explain how prototypes work.

2. Useful if you work with an object that has many methods. Compare:
    let component = {
        doThis(...) { ... },
        doThat(...) { ... },
        doSomethingElse(...} { ... }
    };
    let component = {
        doThis: function (...) { ... },
        doThat: function (...) { ... },
        doSomethingElse: function (...} { ... }
    };

3. Intensely ugly in ES5, clean, simple and universal in ES6.

4. Rarely used, needed for symbols (which make JS much more configurable and cleanly so). Should we use symbols for privacy then this will also allow us do private data elegantly . I’d argue that the latter is much simpler and much more JavaScript-y than what we are doing now (privacy via closures).

5. Rarely used inside object literals, often used for destructuring (pattern matching):
    let {x,y} = computePoint();
    function (required, { opt1, opt2 }) { ... }
    // Also useful for returning things:
    function computePoint() {
        let x = computeX();
        let y = computeY();
        return { x, y };
    }

I see lots of drafts and proposals tend to be from people used to write C(*)/Java or CoffeeScript which is adopted only by a small subset of JavaScript developers who are mainly Rubyists. The fact that some things seem to them as 'acceptable' doesn't mean that comfort with the JavaScript standards and conventions. JavaScript,like all other languages, is not a language to that fits to everyone.

Good point! The new syntax will take a while to get used to, just as JavaScript takes a while to get used to. This is completely new territory, there are no precedents.

Arrow functions are a good example: A more JavaScript-y syntax would have been `fn`:
    let squares = [1,2,3].map(fn(x) { return x*x });
Or:
    let squares = [1,2,3].map(fn(x) x*x);
 
However, due to backward compatibility that syntax wasn’t possible. I think arrow functions are still nice enough:
    let squares = [1,2,3].map(x => x*x);


Axel

-- 
Dr. Axel Rauschmayer



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming talk on ES6 in Russia

André Bargull-2
In reply to this post by Axel Rauschmayer
On March 30, I’ll hold a talk on ECMAScript 6 at CodeFest 2013 in Novosibirsk [1] where I hope to convince people that they have something to look forward to.

A draft of my slides is here, feedback welcome:
http://dl.2ality.com/codefest_es6.pdf

[1] http://2013.codefest.ru/

-- 
Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com


Two minor comments/questions:

Slide 24:
Per draft rev14, "super" references in method definitions within object literals are not allowed (cf. page 117). Did this change recently?
And a missing comma after the __proto__ entry.

Slide 36:
Unless there is an @@iterator on Object.prototype, the first for-of loop doesn't quite work.


- André

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming talk on ES6 in Russia

Axel Rauschmayer
Slide 24:
Per draft rev14, "super" references in method definitions within object literals are not allowed (cf. page 117). Did this change recently?

No, it didn’t. super should indeed not be in there. Furthermore, as denom’s feedback has shown me, I needed to break up that slide (now there are two slides).

And a missing comma after the __proto__ entry.

Slide 36:
Unless there is an @@iterator on Object.prototype, the first for-of loop doesn't quite work.

Thanks, fixed!

-- 
Dr. Axel Rauschmayer



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming talk on ES6 in Russia

Brandon Benvie-2
In reply to this post by Axel Rauschmayer
I also am in camp two
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming talk on ES6 in Russia

Rick Waldron
In reply to this post by denom


On Saturday, March 23, 2013, denom wrote:
Hello Dr. Rauschmayer,
 
Could you plase explain how the slide #23."Object literals" comes in alingment with slide #7."Challenges of evolving a web language" where it is written "Preserve nature of JavaScript" ?
 
The method definitions presenteed on #23 voided anything that JavaScript Object Notation stands for which I consider it is indeed a basic building block of JavaScript and no nature preserved here. 

I suspect you may be conflating Object Literal syntax with JavaScript Object Notation specification—method definitions have never been part of the latter.
 
A mixture of named fucntions, voidance of key/value pairs, and property values shorthand seems like a soup of a little bit of everything and a soup was never a good friend of maintenability of the code. This is monsterous.

The affordance of redundancy removal is actually really fantastic for maintainability ;)


 
I see lots of drafts and proposals tend to be from people used to write C(*)/Java or CoffeeScript 

Can you cite a reference for this claim?

Rick
 
which is adopted only by a small subset of JavaScript developers who are mainly Rubyists. The fact that some things seem to them as 'acceptable' doesn't mean that comfort with the JavaScript standards and conventions. JavaScript,like all other languages, is not a language to that fits to everyone.
 
Best regards,
Dimitris K.
 
------ Original Message ------
From: "Axel Rauschmayer" <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;axel@rauschma.de&#39;);" target="_blank">axel@...>
To: "es-discuss list" <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;es-discuss@mozilla.org&#39;);" target="_blank">es-discuss@...>
Sent: 3/23/2013 6:37:38 PM
Subject: Upcoming talk on ES6 in Russia
On March 30, I’ll hold a talk on ECMAScript 6 at CodeFest 2013 in Novosibirsk [1] where I hope to convince people that they have something to look forward to.

A draft of my slides is here, feedback welcome:
http://dl.2ality.com/codefest_es6.pdf


-- 
Dr. Axel Rauschmayer
<a href="javascript:_e({}, &#39;cvml&#39;, &#39;axel@rauschma.de&#39;);" target="_blank">axel@...



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Upcoming talk on ES6 in Russia

Rick Waldron
In reply to this post by Axel Rauschmayer


On Saturday, March 23, 2013, Axel Rauschmayer wrote:
On March 30, I’ll hold a talk on ECMAScript 6 at CodeFest 2013 in Novosibirsk [1] where I hope to convince people that they have something to look forward to.

A draft of my slides is here, feedback welcome:
http://dl.2ality.com/codefest_es6.pdf

Slide 16
 logHello: function (friends) {
        var that = this;
        friends.forEach(function (friend) {
            console.log(that.name+' says hi to '+friend);
        });

}}


...is a bad example, because unarguably, you're doing wrong: forEach would use its thisArg. I suggest re-factoring to something more painful, eg. a constructor that binds an event handler (like a UI component or similar); creates an interval for itself; provides late-bound, this-sensitive instance methods.

Slide 17, Arrow Function variants is missing (at least) the single arg and zero arg form 

For Set, you could show that enforces a unique list. 

Also, values(), entries(), keys() for map and set?

I'm looking from my phone, so it's possible I missed this: no WeakMap? 


Rick


 




-- 
Dr. Axel Rauschmayer


 

 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming talk on ES6 in Russia

Rick Waldron
In reply to this post by Axel Rauschmayer
I forgot to say: these are lovely slides

Rick

On Saturday, March 23, 2013, Axel Rauschmayer wrote:
On March 30, I’ll hold a talk on ECMAScript 6 at CodeFest 2013 in Novosibirsk [1] where I hope to convince people that they have something to look forward to.

A draft of my slides is here, feedback welcome:
http://dl.2ality.com/codefest_es6.pdf


-- 
Dr. Axel Rauschmayer
<a href="javascript:_e({}, &#39;cvml&#39;, &#39;axel@rauschma.de&#39;);" target="_blank">axel@...



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re[2]: Upcoming talk on ES6 in Russia

denom
In reply to this post by Rick Waldron
 
 
------ Original Message ------
From: "Rick Waldron" <[hidden email]>
To: "denom" <[hidden email]>
Cc: "Axel Rauschmayer" <[hidden email]>; "es-discuss list" <[hidden email]>
Sent: 3/24/2013 12:54:43 AM
Subject: Re: Upcoming talk on ES6 in Russia


On Saturday, March 23, 2013, denom wrote:
Hello Dr. Rauschmayer,
 
Could you plase explain how the slide #23."Object literals" comes in alingment with slide #7."Challenges of evolving a web language" where it is written "Preserve nature of JavaScript" ?
 
The method definitions presenteed on #23 voided anything that JavaScript Object Notation stands for which I consider it is indeed a basic building block of JavaScript and no nature preserved here. 

I suspect you may be conflating Object Literal syntax with JavaScript Object Notation specification—method definitions have never been part of the latter.
 
I don't know in which version of Object Literal definition are you referring but mine goes like this; "An object literal is a list of zero or more pairs of property names and associated values of an object, enclosed in curly braces ({})."
Source : https://developer.mozilla.org/en/docs/JavaScript/Guide/Values,_variables,_and_literals#Object_literals
 which I believe you specifically
A mixture of named fucntions, voidance of key/value pairs, and property values shorthand seems like a soup of a little bit of everything and a soup was never a good friend of maintenability of the code. This is monsterous.

The affordance of redundancy removal is actually really fantastic for maintainability ;)

There is nothing that can be afforded here really. :) And how maintainability gets something out of it?
 
You are attempting to stuff so many things in an object literar that after writting few lines of code inside it you wont even realize that you are in an object literal. Hopefully only a trailing comma on the end of each line will make you suspect it.
 
The worst is that the Homogeneity of JavaScript is cracking widely and that allows developers to split into dogmas between old and new specifications which will want to enforce on projects and is something to be expected. Jumping from one project to another will be like switching between different programming languages at some deegree. Everybody have seen this already with coffeescript (which is kinda cool) but moving to that direction and splitting the JavaScript developers further into groups/dogmas is just not affordable and I can not understand the difficulty some people face comprehending it.
 

 
I see lots of drafts and proposals tend to be from people used to write C(*)/Java or CoffeeScript 

Can you cite a reference for this claim?
 
A reference?? Here.
 
Arrow functions (C# LINQ) : var squares = numbers.forEach(e => e*e );
You can easily run the same code in C#.
 
Destructing Assigment (CoffeeScript), here is a short tutorial http://blog.carbonfive.com/2011/09/28/destructuring-assignment-in-coffeescript/
 
Ruby recently (v. 2.0.0) implemented default parameter values as well like this is proposed in here as well.
 
Classes --> Need to say more?
 
Now , reffering to the above doesn't mean I am against of everything. I am just making a point that influence from other languages is strong but JavaScript is already a well established language(and probably the most widely used) so no need to reinvent everything here and carry every legacy that some sets of contributors got by programming in other languages just because is more comfortable for them. Improve the existing language and respect conventions,notations and syntax of the JavaScript.
 
It will end up as a bastard chaotic set of something different than JavaScript that none will fully understand when, what and how to use.
 
Finally I am really sorry that I had to writte all these in a mail that was not meant for this purpose.

Rick
 
which is adopted only by a small subset of JavaScript developers who are mainly Rubyists. The fact that some things seem to them as 'acceptable' doesn't mean that comfort with the JavaScript standards and conventions. JavaScript,like all other languages, is not a language to that fits to everyone.
 
Best regards,
Dimitris K.
 
------ Original Message ------
From: "Axel Rauschmayer" <<A href="javascript:_e({}, 'cvml', 'axel@rauschma.de');">javascript:_e({}, 'cvml', 'axel@...');>
To: "es-discuss list" <<A href="javascript:_e({}, 'cvml', 'es-discuss@mozilla.org');">javascript:_e({}, 'cvml', 'es-discuss@...');>
Sent: 3/23/2013 6:37:38 PM
Subject: Upcoming talk on ES6 in Russia
On March 30, I’ll hold a talk on ECMAScript 6 at CodeFest 2013 in Novosibirsk [1] where I hope to convince people that they have something to look forward to.

A draft of my slides is here, feedback welcome:
http://dl.2ality.com/codefest_es6.pdf


-- 
Dr. Axel Rauschmayer
<A href="javascript:_e({}, 'cvml', 'axel@rauschma.de');">javascript:_e({}, 'cvml', 'axel@...');



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: Upcoming talk on ES6 in Russia

Rick Waldron



On Sat, Mar 23, 2013 at 9:22 PM, denom <[hidden email]> wrote:
 
 
------ Original Message ------
From: "Rick Waldron" <[hidden email]>
To: "denom" <[hidden email]>
Cc: "Axel Rauschmayer" <[hidden email]>; "es-discuss list" <[hidden email]>
Sent: 3/24/2013 12:54:43 AM
Subject: Re: Upcoming talk on ES6 in Russia


On Saturday, March 23, 2013, denom wrote:
Hello Dr. Rauschmayer,
 
Could you plase explain how the slide #23."Object literals" comes in alingment with slide #7."Challenges of evolving a web language" where it is written "Preserve nature of JavaScript" ?
 
The method definitions presenteed on #23 voided anything that JavaScript Object Notation stands for which I consider it is indeed a basic building block of JavaScript and no nature preserved here. 

I suspect you may be conflating Object Literal syntax with JavaScript Object Notation specification—method definitions have never been part of the latter.
 
I don't know in which version of Object Literal definition are you referring but mine goes like this; "An object literal is a list of zero or more pairs of property names and associated values of an object, enclosed in curly braces ({})."
Source : https://developer.mozilla.org/en/docs/JavaScript/Guide/Values,_variables,_and_literals#Object_literals
 which I believe you specifically


Yes, thank you, but you said...

"The method definitions presenteed on #23 voided anything that JavaScript Object Notation stands for"

And since "JavaScript Object Notation" does not include methods and Axel's slide illustrates _an_ _object_, I'm left to assume you really meant object literal syntax. Please don't cite URLs to non-normative, supplementary content as some kind of evidence to an argument that fails to materialize. 

 
A mixture of named fucntions, voidance of key/value pairs, and property values shorthand seems like a soup of a little bit of everything and a soup was never a good friend of maintenability of the code. This is monsterous.

The affordance of redundancy removal is actually really fantastic for maintainability ;)

There is nothing that can be afforded here really. :) And how maintainability gets something out of it?

It was your claim that the shorthands were "never a good friend of [maintainability]". I argue that code comprehension is improved when there is less in the visible field; comprehension and readability directly inform maintainability. Why you made the claim against maintainability in the first place. Seems like this is less interesting then the next part...
 
 
You are attempting to stuff so many things in an object literar that after writting few lines of code inside it you wont even realize that you are in an object literal. Hopefully only a trailing comma on the end of each line will make you suspect it.
 
The worst is that the Homogeneity of JavaScript is cracking widely and that allows developers to split into dogmas between old and new specifications which will want to enforce on projects and is something to be expected. Jumping from one project to another will be like switching between different programming languages at some deegree. Everybody have seen this already with coffeescript (which is kinda cool) but moving to that direction and splitting the JavaScript developers further into groups/dogmas is just not affordable and I can not understand the difficulty some people face comprehending it.

I'll agree that this example:

let name = 'foo';
let obj = {
    __proto__: SomeObject                 // special prop (1)
    myMethod(arg1, arg2) {           // method definition (2)
        super.myMethod(arg1, arg2);    // super reference (3)
    },
    [name]: 123,                 // computed property key (4)
    bar                       // property value shorthand (5)
}

...is totally insane and I never would've written this for a slide to teach people about these new syntactic forms... but computed properties (the `[name]`) aren't final yet, so remove them from the equation and __proto__ is a lost cause. 

// old
var obj = {
  prop: prop, 
  method: function() {
    ....
  }
};

// new
let obj = {
  prop, 
  method() {
    ....
  }
};

...This is much clearer to read and grok.



 

 

 
I see lots of drafts and proposals tend to be from people used to write C(*)/Java or CoffeeScript 

Can you cite a reference for this claim?
 
A reference?? Here.
 
Arrow functions (C# LINQ) : var squares = numbers.forEach(e => e*e );
You can easily run the same code in C#.
 
Destructing Assigment (CoffeeScript), here is a short tutorial http://blog.carbonfive.com/2011/09/28/destructuring-assignment-in-coffeescript/
 
Ruby recently (v. 2.0.0) implemented default parameter values as well like this is proposed in here as well.
 
Classes --> Need to say more?


What's wrong with allowing good syntactic or semantic design choices inform and inspire? 

 
Now , reffering to the above doesn't mean I am against of everything. I am just making a point that influence from other languages is strong but JavaScript is already a well established language(and probably the most widely used) so no need to reinvent everything here and carry every legacy that some sets of contributors got by programming in other languages just because is more comfortable for them. 
Improve the existing language and respect conventions,notations and syntax of the JavaScript.
 
It will end up as a bastard chaotic set of something different than JavaScript that none will fully understand when, what and how to use.
 
Finally I am really sorry that I had to writte all these in a mail that was not meant for this purpose.

Real technical arguments are welcome, but this is just more negativity and I'm still failing to see what technical points (if any) you're trying to make—beyond telling us all what we _should_ do... It reads like an airing of grievance from atop a soapbox.


Rick 

 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming talk on ES6 in Russia

Jorge Chamorro Bieling
In reply to this post by Axel Rauschmayer
On 23/03/2013, at 19:41, Axel Rauschmayer wrote:
>
> Arrow functions are a good example: A more JavaScript-y syntax would have been `fn`:
>     let squares = [1,2,3].map(fn(x) { return x*x });
> Or:
>     let squares = [1,2,3].map(fn(x) x*x);
>  
> However, due to backward compatibility that syntax wasn’t possible.

I don't think that's true: old code (that doesn't use the new syntax) would continue to run, and new code that opts-in to es6 (using the new syntax) would reject the (very rare) old uses of ƒ as in function ƒ(){} or var ƒ; or ƒ=xxx;, and would allow the new forms, e.g. .map(ƒ(n) ...).

It's ~ the same case as `with` and if they really wanted it could be done, I don't buy the "it wasn't possible", no.

But as bluntly as @rwaldron put it the other day: "arrows are here to stay" (full stop)... well, ok! but I for one don't like them as much.
--
(Jorge)();
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming talk on ES6 in Russia

Brendan Eich-3
Jorge Chamorro wrote:
On 23/03/2013, at 19:41, Axel Rauschmayer wrote:
Arrow functions are a good example: A more JavaScript-y syntax would have been `fn`:
    let squares = [1,2,3].map(fn(x) { return x*x });
Or:
    let squares = [1,2,3].map(fn(x) x*x);
 
However, due to backward compatibility that syntax wasn’t possible.

I don't think that's true: old code (that doesn't use the new syntax) would continue to run, and new code that opts-in to es6 (using the new syntax) would reject the (very rare) old uses of ƒ as in function ƒ(){} or var ƒ; or ƒ=xxx;, and would allow the new forms, e.g. .map(ƒ(n) ...).

If you mean ƒ (florin, option-f on Mac keyboards) then no: the problem is that's an incompatible change and liable to have different meaning in old engines.

(Note also that "new code ... would reject" doesn't make sense: it's an engine that accepts or rejects code.)

a = [1,2,3]
function ƒ(x){return function(y) {return x*y} }
var z = 3
var g = ƒ(z)
z*z
a.map(g) // [3, 6, 9]

In new engines, the initializer for var g is a florin-function expression, ƒ(z) z*z (note the newline before the body expression; note also it doesn't matter whether we use ƒ or fn or something else that's a legal identifier in ES1-6), and the author intends a.map to square the values in [1,2,3].

But in old engines, var g's initializer is a call to ƒ(z), and the z*z on the next line is a useless expression statement.

There's no "would reject" case here. Same input, two different meanings.

Adding a [no LineTerminator here] restriction on the florin-function production between head and body just makes a hazard where removing lines (minification) changes semantics.

It's ~ the same case as `with` and if they really wanted it could be done, I don't buy the "it wasn't possible", no.

'with' has nothing to do with this. It's rejected by ES5 strict, but so what?

But as bluntly as @rwaldron put it the other day: "arrows are here to stay" (full stop)... well, ok! but I for one don't like them as much.

The relevant advantage here is that => was illegal syntax in ES1-5, so there's no backward incompatibility, as there would be for ƒ or fn or similar identifiers.

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss