Re: Javascript Code Churn Rate?

[Isiah Meadows]

With regards to breaking old code, even breaking 0.001% of sites is far too
many for JS. Believe it or not, for similar reasons, __proto__ was
un-deprecated and standardized. And `contains` was changed to `includes`,
because a library popular in the past broke, and a significant number of
their users don't keep their version up to date.

On Tue, Nov 10, 2015, 09:58 Boris Zbarsky  wrote:

> On 11/10/15 7:41 AM, Ethan Resnick wrote:
> > And how long until they could remove support for the rest of the
> > language altogether?
>
> This makes the fundamental assumption that it's OK to break old things
> just because they're old.  To the extent that the web is used for
> applications, this is probably OK, but for documents this is really a
> bad approach because we (well at least some of us) want those to
> continue to be readable as the web evolves.  Otherwise we end up with a
> "dark ages" later on where things that appeared in print continue to be
> readable while later digital stuff, even if still available, is not.
>
> And in this case "documents" includes things like interactive New York
> Times stuff and whatnot...
>
> -Boris
> ___
> 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: Javascript Code Churn Rate?

[Ethan Resnick]

> To the extent that the web is used for applications, this is probably OK,
but for documents this is really a bad approach because we (well at least
some of us) want those to continue to be readable as the web evolves.

Sure, I can appreciate that. And the academic/researcher in me definitely
likes the idea of never removing a language feature.

I guess I was just asking in case anyone felt there could be some (very,
very low) level of breakage that's tolerable. After all, links/images
already go bad pretty regularly and removing bits of JS wouldn't make the
web the only medium for which old equipment (here, an old browser) is
required to view old content. On that front, print is the remarkable
exception; most everything else (audio recordings, video recordings,
conventional software) is pretty tightly bound to its original technology.
Of course, "other mediums suck at longevity too" isn't much of an argument,
but if there's a tradeoff here, maybe it's worth keeping in mind.

Regardless, it seems like there are many less radical approaches that
deprioritize old features without making them strictly unavailable, so I'm
still curious to know about JS churn rates, if that data exists, to get a
sense of the timescale for those approaches.
On Nov 10, 2015 6:58 AM, "Boris Zbarsky"  wrote:

> On 11/10/15 7:41 AM, Ethan Resnick wrote:
>
>> And how long until they could remove support for the rest of the
>> language altogether?
>>
>
> This makes the fundamental assumption that it's OK to break old things
> just because they're old.  To the extent that the web is used for
> applications, this is probably OK, but for documents this is really a bad
> approach because we (well at least some of us) want those to continue to be
> readable as the web evolves.  Otherwise we end up with a "dark ages" later
> on where things that appeared in print continue to be readable while later
> digital stuff, even if still available, is not.
>
> And in this case "documents" includes things like interactive New York
> Times stuff and whatnot...
>
> -Boris
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Javascript Code Churn Rate?

[William Edney]

I'd like to chime in here as this is a pet peeve of mine.

In general, I'd say that the ECMAScript working group and engine vendors
have done a better job at handling this than the other Web-related
technologies groups (in particular, the DOM working group).  In specific,
I'm thinking of how the ECMAScript group handed 'non-strict' / 'strict' vs.
the DOM group's heavy-handed attempt to change Attributes to not be Nodes
and the fallout from that for me and my company's product.

The core problem, in my opinion, stems from this misguided attempt to
'telemeter' the Web and then use that as justification for removing
features. This is all fine and dandy if you only ever live in the 'Internet
world', where folks do monthly, if not daily, releases but many of us
don't. We are building Web apps (*lots and lots* of Web apps) for
enterprises who have a firewall that your telemetry will never measure.
This code was built long ago, its developers donned their white hat and
rode into the sunset a while back and it's expected usable lifetime is
measured in years, not months.

When asked by these developers when I expect that they can remove these
features, my answer is: "think years... maybe decades." We're working in
environments where we're replacing mainframe systems that were written when
Jimmy Carter was president (apologies to non-US citizens here, that
would've been in the late 1970's). The customers we're doing the work for
expect that the "new" systems are going to last as long, unrealistic though
that may be.

Here's another way to think about it: *Java* API evolution speeds.

My 2 cents.

Cheers,

- Bill

On Tue, Nov 10, 2015 at 10:47 AM, Ethan Resnick 
wrote:

> > To the extent that the web is used for applications, this is probably
> OK, but for documents this is really a bad approach because we (well at
> least some of us) want those to continue to be readable as the web evolves.
>
> Sure, I can appreciate that. And the academic/researcher in me definitely
> likes the idea of never removing a language feature.
>
> I guess I was just asking in case anyone felt there could be some (very,
> very low) level of breakage that's tolerable. After all, links/images
> already go bad pretty regularly and removing bits of JS wouldn't make the
> web the only medium for which old equipment (here, an old browser) is
> required to view old content. On that front, print is the remarkable
> exception; most everything else (audio recordings, video recordings,
> conventional software) is pretty tightly bound to its original technology.
> Of course, "other mediums suck at longevity too" isn't much of an argument,
> but if there's a tradeoff here, maybe it's worth keeping in mind.
>
> Regardless, it seems like there are many less radical approaches that
> deprioritize old features without making them strictly unavailable, so I'm
> still curious to know about JS churn rates, if that data exists, to get a
> sense of the timescale for those approaches.
> On Nov 10, 2015 6:58 AM, "Boris Zbarsky"  wrote:
>
>> On 11/10/15 7:41 AM, Ethan Resnick wrote:
>>
>>> And how long until they could remove support for the rest of the
>>> language altogether?
>>>
>>
>> This makes the fundamental assumption that it's OK to break old things
>> just because they're old.  To the extent that the web is used for
>> applications, this is probably OK, but for documents this is really a bad
>> approach because we (well at least some of us) want those to continue to be
>> readable as the web evolves.  Otherwise we end up with a "dark ages" later
>> on where things that appeared in print continue to be readable while later
>> digital stuff, even if still available, is not.
>>
>> And in this case "documents" includes things like interactive New York
>> Times stuff and whatnot...
>>
>> -Boris
>>
>
> ___
> 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

The "Pipeline" Operator - Making multiple function calls look great

[Gilbert B Garza]

Hello, I'm a JavaScript programmer and instructor who loves functional
programming and writing concise, readable code. I think in general
JavaScript supports programming in a functional style quite well. However,
there is one small missing piece that I miss from other FP languages: the
simple-yet-useful pipeline operator.

Similar to F#, Elixir, Elm, and other FP languages, the pipeline operator
|> helps make multiple function invocations more readable. Basically,
`sqrt(64)` is equivalent to `64 |> sqrt`. For example, given the following
functions:

```js
function doubleSay (str) { return str + ", " + str; }
function capitalize (str) { return str[0].toUpperCase() + str.substring(1);
}
function exclaim (str) { return str + '!'; }
```

you could use the pipeline operator to expand your invocations for
readability:

```js
// old way:
// var result = exclaim(capitalize(doubleSay("hello")));

// new way:
var result = "hello"
  |> doubleSay
  |> capitalize
  |> exclaim;

// or, if you like one-liners:
var result = "hello" |> doubleSay |> capitalize |> exclaim

result //=> "Hello, hello!"
```

You can see a few more examples, including an advanced example with
Promises, here: https://github.com/mindeavor/ES7-pipeline-operator

I'm inclined to think this feature is small and straight-forward to
implement. Other than the operator, there are no new semantics. The syntax
transformation is simple, and all existing code would remain unaffected.

Although small, this feature increases the expressiveness of JavaScript
significantly by opening more API design possibilities. You can see this in
the link I included above.

Thanks for reading. Any thoughts or comments?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Javascript Code Churn Rate?

[Boris Zbarsky]

On 11/10/15 7:41 AM, Ethan Resnick wrote:

And how long until they could remove support for the rest of the
language altogether?


This makes the fundamental assumption that it's OK to break old things 
just because they're old.  To the extent that the web is used for 
applications, this is probably OK, but for documents this is really a 
bad approach because we (well at least some of us) want those to 
continue to be readable as the web evolves.  Otherwise we end up with a 
"dark ages" later on where things that appeared in print continue to be 
readable while later digital stuff, even if still available, is not.


And in this case "documents" includes things like interactive New York 
Times stuff and whatnot...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "Pipeline" Operator - Making multiple function calls look great

[Alexander Fritze]

I agree 100% that this would make a great addition to JS!

We've had the pipeline operator in Stratified JS for a while - see
https://conductance.io/reference#sjs:%23language/syntax::double-dot -
, and in our experience it makes a lot of code much more readable.

We call it '..' (the 'doubledot operator') instead of '|>' - IMO this
feels more aligned with existing JS syntax and less jarring than '|>'.


On Tue, Nov 10, 2015 at 10:54 AM, Gilbert B Garza
 wrote:
> Hello, I'm a JavaScript programmer and instructor who loves functional
> programming and writing concise, readable code. I think in general
> JavaScript supports programming in a functional style quite well. However,
> there is one small missing piece that I miss from other FP languages: the
> simple-yet-useful pipeline operator.
>
> Similar to F#, Elixir, Elm, and other FP languages, the pipeline operator |>
> helps make multiple function invocations more readable. Basically,
> `sqrt(64)` is equivalent to `64 |> sqrt`. For example, given the following
> functions:
>
> ```js
> function doubleSay (str) { return str + ", " + str; }
> function capitalize (str) { return str[0].toUpperCase() + str.substring(1);
> }
> function exclaim (str) { return str + '!'; }
> ```
>
> you could use the pipeline operator to expand your invocations for
> readability:
>
> ```js
> // old way:
> // var result = exclaim(capitalize(doubleSay("hello")));
>
> // new way:
> var result = "hello"
>   |> doubleSay
>   |> capitalize
>   |> exclaim;
>
> // or, if you like one-liners:
> var result = "hello" |> doubleSay |> capitalize |> exclaim
>
> result //=> "Hello, hello!"
> ```
>
> You can see a few more examples, including an advanced example with
> Promises, here: https://github.com/mindeavor/ES7-pipeline-operator
>
> I'm inclined to think this feature is small and straight-forward to
> implement. Other than the operator, there are no new semantics. The syntax
> transformation is simple, and all existing code would remain unaffected.
>
> Although small, this feature increases the expressiveness of JavaScript
> significantly by opening more API design possibilities. You can see this in
> the link I included above.
>
> Thanks for reading. Any thoughts or comments?
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Alexander Fritze
http://onilabs.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Javascript Code Churn Rate?

[William Edney]

For clarification in my earlier message, when I say "asked by these
developers", I'm speaking of members of browser development teams.

Cheers,

- Bill

On Tue, Nov 10, 2015 at 11:08 AM, William Edney  wrote:

> I'd like to chime in here as this is a pet peeve of mine.
>
> In general, I'd say that the ECMAScript working group and engine vendors
> have done a better job at handling this than the other Web-related
> technologies groups (in particular, the DOM working group).  In specific,
> I'm thinking of how the ECMAScript group handed 'non-strict' / 'strict' vs.
> the DOM group's heavy-handed attempt to change Attributes to not be Nodes
> and the fallout from that for me and my company's product.
>
> The core problem, in my opinion, stems from this misguided attempt to
> 'telemeter' the Web and then use that as justification for removing
> features. This is all fine and dandy if you only ever live in the 'Internet
> world', where folks do monthly, if not daily, releases but many of us
> don't. We are building Web apps (*lots and lots* of Web apps) for
> enterprises who have a firewall that your telemetry will never measure.
> This code was built long ago, its developers donned their white hat and
> rode into the sunset a while back and it's expected usable lifetime is
> measured in years, not months.
>
> When asked by these developers when I expect that they can remove these
> features, my answer is: "think years... maybe decades." We're working in
> environments where we're replacing mainframe systems that were written when
> Jimmy Carter was president (apologies to non-US citizens here, that
> would've been in the late 1970's). The customers we're doing the work for
> expect that the "new" systems are going to last as long, unrealistic though
> that may be.
>
> Here's another way to think about it: *Java* API evolution speeds.
>
> My 2 cents.
>
> Cheers,
>
> - Bill
>
> On Tue, Nov 10, 2015 at 10:47 AM, Ethan Resnick 
> wrote:
>
>> > To the extent that the web is used for applications, this is probably
>> OK, but for documents this is really a bad approach because we (well at
>> least some of us) want those to continue to be readable as the web evolves.
>>
>> Sure, I can appreciate that. And the academic/researcher in me definitely
>> likes the idea of never removing a language feature.
>>
>> I guess I was just asking in case anyone felt there could be some (very,
>> very low) level of breakage that's tolerable. After all, links/images
>> already go bad pretty regularly and removing bits of JS wouldn't make the
>> web the only medium for which old equipment (here, an old browser) is
>> required to view old content. On that front, print is the remarkable
>> exception; most everything else (audio recordings, video recordings,
>> conventional software) is pretty tightly bound to its original technology.
>> Of course, "other mediums suck at longevity too" isn't much of an argument,
>> but if there's a tradeoff here, maybe it's worth keeping in mind.
>>
>> Regardless, it seems like there are many less radical approaches that
>> deprioritize old features without making them strictly unavailable, so I'm
>> still curious to know about JS churn rates, if that data exists, to get a
>> sense of the timescale for those approaches.
>> On Nov 10, 2015 6:58 AM, "Boris Zbarsky"  wrote:
>>
>>> On 11/10/15 7:41 AM, Ethan Resnick wrote:
>>>
 And how long until they could remove support for the rest of the
 language altogether?

>>>
>>> This makes the fundamental assumption that it's OK to break old things
>>> just because they're old.  To the extent that the web is used for
>>> applications, this is probably OK, but for documents this is really a bad
>>> approach because we (well at least some of us) want those to continue to be
>>> readable as the web evolves.  Otherwise we end up with a "dark ages" later
>>> on where things that appeared in print continue to be readable while later
>>> digital stuff, even if still available, is not.
>>>
>>> And in this case "documents" includes things like interactive New York
>>> Times stuff and whatnot...
>>>
>>> -Boris
>>>
>>
>> ___
>> 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: The "Pipeline" Operator - Making multiple function calls look great

[Kevin Smith]

>
> - I don't like the requirement to use the keyword `this` to compose
> functions. JS already has many features to support the keyword `this`:
> prototypes, method invocations, function binding, arrow functions, and
> probably others. I prefer a feature that assists the other side of the
> spectrum.
>

Yep - a well documented critique.  It depends on your point of view, I
think.  If you view these things as "extension methods", then using `this`
makes more sense.

- The fact that there are new semantics to what looks like a normal
> function call (e.g. `->map(...)`) doesn't set well with me. You could argue
> that it's something to get used to. Even in that case, I would expect the
> first argument I give to `map` to stay the first argument.
>

This is a reasonable objection, I think.

With the pipeline operator, partial application is left to the developer.
> They can choose to use arrow functions, or to curry their functions. I
> think this is the best option since it keeps things simple (no new
> semantics), and remains readable – see the "Function with Multiple
> Arguments" section in the GitHub link
> https://github.com/mindeavor/ES7-pipeline-operator
>

I agree that your proposal wins points for simplicity (both semantic and
syntactic), but having to create an arrow function to pass more than one
argument feels a bit awkward and seems to defeat some of the readability
benefit.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "Pipeline" Operator - Making multiple function calls look great

[Isiah Meadows]

Inline

On Tue, Nov 10, 2015 at 12:52 PM, Kevin Smith  wrote:
>> - I don't like the requirement to use the keyword `this` to compose
>> functions. JS already has many features to support the keyword `this`:
>> prototypes, method invocations, function binding, arrow functions, and
>> probably others. I prefer a feature that assists the other side of the
>> spectrum.
>
>
> Yep - a well documented critique.  It depends on your point of view, I
> think.  If you view these things as "extension methods", then using `this`
> makes more sense.
>
>> - The fact that there are new semantics to what looks like a normal
>> function call (e.g. `->map(...)`) doesn't set well with me. You could argue
>> that it's something to get used to. Even in that case, I would expect the
>> first argument I give to `map` to stay the first argument.
>
>
> This is a reasonable objection, I think.

Not to mention it's still a point of contention:
https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932
(from here, down)

>
>> With the pipeline operator, partial application is left to the developer.
>> They can choose to use arrow functions, or to curry their functions. I think
>> this is the best option since it keeps things simple (no new semantics), and
>> remains readable – see the "Function with Multiple Arguments" section in the
>> GitHub link https://github.com/mindeavor/ES7-pipeline-operator
>
>
> I agree that your proposal wins points for simplicity (both semantic and
> syntactic), but having to create an arrow function to pass more than one
> argument feels a bit awkward and seems to defeat some of the readability
> benefit.

Not to mention it would be pretty slow. That's going to be creating a
closure each call. Engines still struggle with making closures fast.
It's non-trivial at runtime to create a closure that's performant.

>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Isiah Meadows
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "Pipeline" Operator - Making multiple function calls look great

[Kevin Smith]

Hi Gilbert,

Have you seen https://github.com/zenparsing/es-function-bind/ ?  It's a
function bind-syntax proposal which covers some of the same use cases
(although by binding the `this` parameter instead of passing the first
arg).  We've also explored some alternatives more closely aligned with your
proposal.  Check out the discussion here for the latest state:
https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154237803
and
feel free to comment!

On Tue, Nov 10, 2015 at 11:54 AM Gilbert B Garza 
wrote:

> Hello, I'm a JavaScript programmer and instructor who loves functional
> programming and writing concise, readable code. I think in general
> JavaScript supports programming in a functional style quite well. However,
> there is one small missing piece that I miss from other FP languages: the
> simple-yet-useful pipeline operator.
>
> Similar to F#, Elixir, Elm, and other FP languages, the pipeline operator
> |> helps make multiple function invocations more readable. Basically,
> `sqrt(64)` is equivalent to `64 |> sqrt`. For example, given the following
> functions:
>
> ```js
> function doubleSay (str) { return str + ", " + str; }
> function capitalize (str) { return str[0].toUpperCase() +
> str.substring(1); }
> function exclaim (str) { return str + '!'; }
> ```
>
> you could use the pipeline operator to expand your invocations for
> readability:
>
> ```js
> // old way:
> // var result = exclaim(capitalize(doubleSay("hello")));
>
> // new way:
> var result = "hello"
>   |> doubleSay
>   |> capitalize
>   |> exclaim;
>
> // or, if you like one-liners:
> var result = "hello" |> doubleSay |> capitalize |> exclaim
>
> result //=> "Hello, hello!"
> ```
>
> You can see a few more examples, including an advanced example with
> Promises, here: https://github.com/mindeavor/ES7-pipeline-operator
>
> I'm inclined to think this feature is small and straight-forward to
> implement. Other than the operator, there are no new semantics. The syntax
> transformation is simple, and all existing code would remain unaffected.
>
> Although small, this feature increases the expressiveness of JavaScript
> significantly by opening more API design possibilities. You can see this in
> the link I included above.
>
> Thanks for reading. Any thoughts or comments?
> ___
> 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: The "Pipeline" Operator - Making multiple function calls look great

[Felipe Nascimento de Moura]

I find this interesting, indeed.

Although, I believe the ( ) are like "representations OF a function call".
I felt like if there was something missing there!
What about something like this, then?

// exclaim(capitalize(doubleSay("hello")));
doubleSay("hello") |> capitalize |> exclaim;

For me, this feels like "calling doubleSay", then passing its results for
capitalize, and its result to exclaim.

Some interesting implementations coupd be done with async await, I believe!




On Tue, Nov 10, 2015 at 3:09 PM, Alexander Fritze  wrote:

> I agree 100% that this would make a great addition to JS!
>
> We've had the pipeline operator in Stratified JS for a while - see
> https://conductance.io/reference#sjs:%23language/syntax::double-dot -
> , and in our experience it makes a lot of code much more readable.
>
> We call it '..' (the 'doubledot operator') instead of '|>' - IMO this
> feels more aligned with existing JS syntax and less jarring than '|>'.
>
>
> On Tue, Nov 10, 2015 at 10:54 AM, Gilbert B Garza
>  wrote:
> > Hello, I'm a JavaScript programmer and instructor who loves functional
> > programming and writing concise, readable code. I think in general
> > JavaScript supports programming in a functional style quite well.
> However,
> > there is one small missing piece that I miss from other FP languages: the
> > simple-yet-useful pipeline operator.
> >
> > Similar to F#, Elixir, Elm, and other FP languages, the pipeline
> operator |>
> > helps make multiple function invocations more readable. Basically,
> > `sqrt(64)` is equivalent to `64 |> sqrt`. For example, given the
> following
> > functions:
> >
> > ```js
> > function doubleSay (str) { return str + ", " + str; }
> > function capitalize (str) { return str[0].toUpperCase() +
> str.substring(1);
> > }
> > function exclaim (str) { return str + '!'; }
> > ```
> >
> > you could use the pipeline operator to expand your invocations for
> > readability:
> >
> > ```js
> > // old way:
> > // var result = exclaim(capitalize(doubleSay("hello")));
> >
> > // new way:
> > var result = "hello"
> >   |> doubleSay
> >   |> capitalize
> >   |> exclaim;
> >
> > // or, if you like one-liners:
> > var result = "hello" |> doubleSay |> capitalize |> exclaim
> >
> > result //=> "Hello, hello!"
> > ```
> >
> > You can see a few more examples, including an advanced example with
> > Promises, here: https://github.com/mindeavor/ES7-pipeline-operator
> >
> > I'm inclined to think this feature is small and straight-forward to
> > implement. Other than the operator, there are no new semantics. The
> syntax
> > transformation is simple, and all existing code would remain unaffected.
> >
> > Although small, this feature increases the expressiveness of JavaScript
> > significantly by opening more API design possibilities. You can see this
> in
> > the link I included above.
> >
> > Thanks for reading. Any thoughts or comments?
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
> --
> Alexander Fritze
> http://onilabs.com
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
*Felipe N. Moura*
Senior Web Developer and System Analyst.

Website:  http://felipenmoura.com
Twitter:@felipenmoura 
LinkedIn: http://goo.gl/qGmq

Meet some of my projects:
BrazilJS Conference   |  BrazilJS Foundation

-
*Changing  the  world*  is the least I expect from  myself!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Generator getter method

[Mohsen Azimi]

Can we allow generator getter methods?

Here is an example use case:

```
let rectangle = {
  start: {x: 1, y: 5},
  width: 2,
  height: 3,

  *getCorners() {
let {x: startX, y: startY} = this.start;
yield this.start;
yield {x: startX + this.width, y: startY};
yield {x: startX + this.width, y: startY + this.height};
yield {x: startX, y: startY + this.height}
  }
}

for (let corner of rectangle.getCorners()) {
  console.log(corner);
}
```

I'm proposing to allow  `get coreners* () { ...` (a generator getter
method) so the for..of loop can be written like this:

```
for (let corner of rectangle.corners) {
  console.log(corner);
}
```

Which seems cleaner
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "Pipeline" Operator - Making multiple function calls look great

[Gilbert B Garza]

Kevin: Ah yes, I have studied function-bind, but I have two issues with it:

- I don't like the requirement to use the keyword `this` to compose
functions. JS already has many features to support the keyword `this`:
prototypes, method invocations, function binding, arrow functions, and
probably others. I prefer a feature that assists the other side of the
spectrum.

- The fact that there are new semantics to what looks like a normal
function call (e.g. `->map(...)`) doesn't set well with me. You could argue
that it's something to get used to. Even in that case, I would expect the
first argument I give to `map` to stay the first argument.

With the pipeline operator, partial application is left to the developer.
They can choose to use arrow functions, or to curry their functions. I
think this is the best option since it keeps things simple (no new
semantics), and remains readable – see the "Function with Multiple
Arguments" section in the GitHub link
https://github.com/mindeavor/ES7-pipeline-operator

On Tue, Nov 10, 2015 at 11:15 AM, Kevin Smith  wrote:

> Hi Gilbert,
>
> Have you seen https://github.com/zenparsing/es-function-bind/ ?  It's a
> function bind-syntax proposal which covers some of the same use cases
> (although by binding the `this` parameter instead of passing the first
> arg).  We've also explored some alternatives more closely aligned with your
> proposal.  Check out the discussion here for the latest state:
> https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154237803
>  and
> feel free to comment!
>
> On Tue, Nov 10, 2015 at 11:54 AM Gilbert B Garza 
> wrote:
>
>> Hello, I'm a JavaScript programmer and instructor who loves functional
>> programming and writing concise, readable code. I think in general
>> JavaScript supports programming in a functional style quite well. However,
>> there is one small missing piece that I miss from other FP languages: the
>> simple-yet-useful pipeline operator.
>>
>> Similar to F#, Elixir, Elm, and other FP languages, the pipeline operator
>> |> helps make multiple function invocations more readable. Basically,
>> `sqrt(64)` is equivalent to `64 |> sqrt`. For example, given the following
>> functions:
>>
>> ```js
>> function doubleSay (str) { return str + ", " + str; }
>> function capitalize (str) { return str[0].toUpperCase() +
>> str.substring(1); }
>> function exclaim (str) { return str + '!'; }
>> ```
>>
>> you could use the pipeline operator to expand your invocations for
>> readability:
>>
>> ```js
>> // old way:
>> // var result = exclaim(capitalize(doubleSay("hello")));
>>
>> // new way:
>> var result = "hello"
>>   |> doubleSay
>>   |> capitalize
>>   |> exclaim;
>>
>> // or, if you like one-liners:
>> var result = "hello" |> doubleSay |> capitalize |> exclaim
>>
>> result //=> "Hello, hello!"
>> ```
>>
>> You can see a few more examples, including an advanced example with
>> Promises, here: https://github.com/mindeavor/ES7-pipeline-operator
>>
>> I'm inclined to think this feature is small and straight-forward to
>> implement. Other than the operator, there are no new semantics. The syntax
>> transformation is simple, and all existing code would remain unaffected.
>>
>> Although small, this feature increases the expressiveness of JavaScript
>> significantly by opening more API design possibilities. You can see this in
>> the link I included above.
>>
>> Thanks for reading. Any thoughts or comments?
>> ___
>> 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: The "Pipeline" Operator - Making multiple function calls look great

[Gilbert B Garza]

>
> Although, I believe the ( ) are like "representations OF a function call".
> I felt like if there was something missing there!
> What about something like this, then?
>


// exclaim(capitalize(doubleSay("hello")));
> doubleSay("hello") |> capitalize |> exclaim;


Felipe: That is perfectly valid syntax under the current proposal, and you
are free to choose to write your code in that way :)

On Tue, Nov 10, 2015 at 11:15 AM, Felipe Nascimento de Moura <
felipenmo...@gmail.com> wrote:

> I find this interesting, indeed.
>
>
> For me, this feels like "calling doubleSay", then passing its results for
> capitalize, and its result to exclaim.
>
> Some interesting implementations coupd be done with async await, I believe!
>
>
>
>
> On Tue, Nov 10, 2015 at 3:09 PM, Alexander Fritze 
> wrote:
>
>> I agree 100% that this would make a great addition to JS!
>>
>> We've had the pipeline operator in Stratified JS for a while - see
>> https://conductance.io/reference#sjs:%23language/syntax::double-dot -
>> , and in our experience it makes a lot of code much more readable.
>>
>> We call it '..' (the 'doubledot operator') instead of '|>' - IMO this
>> feels more aligned with existing JS syntax and less jarring than '|>'.
>>
>>
>> On Tue, Nov 10, 2015 at 10:54 AM, Gilbert B Garza
>>  wrote:
>> > Hello, I'm a JavaScript programmer and instructor who loves functional
>> > programming and writing concise, readable code. I think in general
>> > JavaScript supports programming in a functional style quite well.
>> However,
>> > there is one small missing piece that I miss from other FP languages:
>> the
>> > simple-yet-useful pipeline operator.
>> >
>> > Similar to F#, Elixir, Elm, and other FP languages, the pipeline
>> operator |>
>> > helps make multiple function invocations more readable. Basically,
>> > `sqrt(64)` is equivalent to `64 |> sqrt`. For example, given the
>> following
>> > functions:
>> >
>> > ```js
>> > function doubleSay (str) { return str + ", " + str; }
>> > function capitalize (str) { return str[0].toUpperCase() +
>> str.substring(1);
>> > }
>> > function exclaim (str) { return str + '!'; }
>> > ```
>> >
>> > you could use the pipeline operator to expand your invocations for
>> > readability:
>> >
>> > ```js
>> > // old way:
>> > // var result = exclaim(capitalize(doubleSay("hello")));
>> >
>> > // new way:
>> > var result = "hello"
>> >   |> doubleSay
>> >   |> capitalize
>> >   |> exclaim;
>> >
>> > // or, if you like one-liners:
>> > var result = "hello" |> doubleSay |> capitalize |> exclaim
>> >
>> > result //=> "Hello, hello!"
>> > ```
>> >
>> > You can see a few more examples, including an advanced example with
>> > Promises, here: https://github.com/mindeavor/ES7-pipeline-operator
>> >
>> > I'm inclined to think this feature is small and straight-forward to
>> > implement. Other than the operator, there are no new semantics. The
>> syntax
>> > transformation is simple, and all existing code would remain unaffected.
>> >
>> > Although small, this feature increases the expressiveness of JavaScript
>> > significantly by opening more API design possibilities. You can see
>> this in
>> > the link I included above.
>> >
>> > Thanks for reading. Any thoughts or comments?
>> >
>> > ___
>> > es-discuss mailing list
>> > es-discuss@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>>
>>
>>
>> --
>> Alexander Fritze
>> http://onilabs.com
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
> *Felipe N. Moura*
> Senior Web Developer and System Analyst.
>
> Website:  http://felipenmoura.com
> Twitter:@felipenmoura 
> LinkedIn: http://goo.gl/qGmq
>
> Meet some of my projects:
> BrazilJS Conference   |  BrazilJS Foundation
> 
> -
> *Changing  the  world*  is the least I expect from  myself!
>
> ___
> 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: Generator getter method

[Kevin Smith]

The existing option is:

let rect = {
  get corners() { return this._corners(); },
  *_corners() { .. },
};

which doesn't seem so bad.  Also, a generator getter would introduce a bit
of divergence between getter and setter syntax.

On Tue, Nov 10, 2015 at 2:28 PM Mohsen Azimi  wrote:

> Can we allow generator getter methods?
>
> Here is an example use case:
>
> ```
> let rectangle = {
>   start: {x: 1, y: 5},
>   width: 2,
>   height: 3,
>
>   *getCorners() {
> let {x: startX, y: startY} = this.start;
> yield this.start;
> yield {x: startX + this.width, y: startY};
> yield {x: startX + this.width, y: startY + this.height};
> yield {x: startX, y: startY + this.height}
>   }
> }
>
> for (let corner of rectangle.getCorners()) {
>   console.log(corner);
> }
> ```
>
> I'm proposing to allow  `get coreners* () { ...` (a generator getter
> method) so the for..of loop can be written like this:
>
> ```
> for (let corner of rectangle.corners) {
>   console.log(corner);
> }
> ```
>
> Which seems cleaner
> ___
> 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: The "Pipeline" Operator - Making multiple function calls look great

[Gilbert B Garza]

>
> I agree that your proposal wins points for simplicity (both semantic and
> syntactic), but having to create an arrow function to pass more than one
> argument feels a bit awkward and seems to defeat some of the readability
> benefit.


I find it to be pleasant :) It gives opportunity to semantically name your
arrow function parameter, and it also follows the consistency of "the value
on the left gets fed to the function on the right".

But yes, I do agree having partial application somehow built-in would be
nice.


Not to mention it would be pretty slow. That's going to be creating a closure
> each call.


Normally yes, but since the pipeline operator is a pure function, I think
it's possible for the compiler to optimize away the intermediate arrow
functions. I mention this in the "Functions with Multiple Arguments"
section
https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments


On Tue, Nov 10, 2015 at 12:52 PM, Isiah Meadows 
wrote:

> Inline
>
> On Tue, Nov 10, 2015 at 12:52 PM, Kevin Smith 
> wrote:
> >> - I don't like the requirement to use the keyword `this` to compose
> >> functions. JS already has many features to support the keyword `this`:
> >> prototypes, method invocations, function binding, arrow functions, and
> >> probably others. I prefer a feature that assists the other side of the
> >> spectrum.
> >
> >
> > Yep - a well documented critique.  It depends on your point of view, I
> > think.  If you view these things as "extension methods", then using
> `this`
> > makes more sense.
> >
> >> - The fact that there are new semantics to what looks like a normal
> >> function call (e.g. `->map(...)`) doesn't set well with me. You could
> argue
> >> that it's something to get used to. Even in that case, I would expect
> the
> >> first argument I give to `map` to stay the first argument.
> >
> >
> > This is a reasonable objection, I think.
>
> Not to mention it's still a point of contention:
>
> https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932
> (from here, down)
>
> >
> >> With the pipeline operator, partial application is left to the
> developer.
> >> They can choose to use arrow functions, or to curry their functions. I
> think
> >> this is the best option since it keeps things simple (no new
> semantics), and
> >> remains readable – see the "Function with Multiple Arguments" section
> in the
> >> GitHub link https://github.com/mindeavor/ES7-pipeline-operator
> >
> >
> > I agree that your proposal wins points for simplicity (both semantic and
> > syntactic), but having to create an arrow function to pass more than one
> > argument feels a bit awkward and seems to defeat some of the readability
> > benefit.
>
> Not to mention it would be pretty slow. That's going to be creating a
> closure each call. Engines still struggle with making closures fast.
> It's non-trivial at runtime to create a closure that's performant.
>
> >
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
> --
> Isiah Meadows
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "Pipeline" Operator - Making multiple function calls look great

[Nelo Mitranim]

Seems pointless. Functions can be trivially composed to form a “pipeline” 
without introducing new syntax: https://lodash.com/docs#flow
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "Pipeline" Operator - Making multiple function calls look great

[Isiah Meadows]

Not with your semantics. It has to generate a closure each time, because of
the possibility it can't be used elsewhere. That's impossible to know ahead
of time if the variable is ever used outside of its closure or as a value.
In the case below, it should only log thrice. Otherwise, it's unexpected
behavior.

```js
function add(x) {
  console.log("Hit!");
  return y => x + y;
}

let inc = add(1);

1 |> inc |> inc |> add(2) |> add(3);

// Hit!
// Hit!
// Hit!
```

On Tue, Nov 10, 2015, 15:08 Gilbert B Garza  wrote:

Normally yes, but since the pipeline operator is a pure function, I think
it's possible for the compiler to optimize away the intermediate arrow
functions. I mention this in the "Functions with Multiple Arguments"
section https

://

github.com

/

mindeavor

/

ES7-pipeline-operator#functions

-with-multiple-arguments



On Tue, Nov 10, 2015 at 12:52 PM, Isiah Meadows 
wrote:

Inline

On Tue, Nov 10, 2015 at 12:52 PM, Kevin Smith  wrote:
>> - I don't like the requirement to use the keyword `this` to compose
>> functions. JS already has many features to support the keyword `this`:
>> prototypes, method invocations, function binding, arrow functions, and
>> probably others. I prefer a feature that assists the other side of the
>> spectrum.
>
>
> Yep - a well documented critique.  It depends on your point of view, I
> think.  If you view these things as "extension methods", then using `this`
> makes more sense.
>
>> - The fact that there are new semantics to what looks like a normal
>> function call (e.g. `->map(...)`) doesn't set well with me. You could
argue
>> that it's something to get used to. Even in that case, I would expect the
>> first argument I give to `map` to stay the first argument.
>
>
> This is a reasonable objection, I think.

Not to mention it's still a point of contention:
https

://

github.com

/

zenparsing

/

es-function-bind

/issues/26#issuecomment-154130932

(from here, down)

>
>> With the pipeline operator, partial application is left to the developer.
>> They can choose to use arrow functions, or to curry their functions. I
think
>> this is the best option since it keeps things simple (no new semantics),
and
>> remains readable – see the "Function with Multiple Arguments" section in
the
>> GitHub link https ://
github.com
/
mindeavor
/
ES7-pipeline-operator

>
>
> I agree that your proposal wins points for simplicity (both semantic and
> syntactic), but having to create an arrow function to pass more than one
> argument feels a bit awkward and seems to defeat some of the readability
> benefit.

Not to mention it would be pretty slow. That's going to be creating a
closure each call. Engines still struggle with making closures fast.
It's non-trivial at runtime to create a closure that's performant.

>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https ://
mail.mozilla.org
/
listinfo
/
es-discuss

Re: Concise Method Binding

[Rick Waldron]

On Mon, Nov 9, 2015 at 8:45 PM JD Isaacks  wrote:

> Considering the proposals for both concise methods and the bind operator I
> think it would be a great addition to be able to use them together.
>
> I am already seeing a lot of this:
>
> class Foo {
>   bar = () => {
> // bound
>   }
>   buz() {
> // unbound
>   }
> }
>
>
>
Can you clarify what this is, because it's not valid ES6 code. Also,
"bound" and "unbound" in what sense? In `buz`, the `this` object will be
the instance of Foo from which it's called.

Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "Pipeline" Operator - Making multiple function calls look great

[Gilbert B Garza]

Ah, sorry for being unclear. You're right, in the case of manual currying,
the closure can not and should not be optimized away.

I was talking about the case where you have arrow function literals. For
example:

```js
var bounded = 750
|> s => Math.max(100, s)
|> s => Math.min(0, s);
```

I imagine if the compiler sees arrow functions used in this specific
manner, it could automatically optimize to the following:

```js
var bounded = Math.min( 0, Math.max(100, 750) )
```

Semantically, they are equivalent; no closures nor scopes were effectively
used in the intermediary arrow functions.


On Tue, Nov 10, 2015 at 4:34 PM, Isiah Meadows 
wrote:

> Not with your semantics. It has to generate a closure each time, because
> of the possibility it can't be used elsewhere. That's impossible to know
> ahead of time if the variable is ever used outside of its closure or as a
> value. In the case below, it should only log thrice. Otherwise, it's
> unexpected behavior.
>
> ```js
> function add(x) {
>   console.log("Hit!");
>   return y => x + y;
> }
>
> let inc = add(1);
>
> 1 |> inc |> inc |> add(2) |> add(3);
>
> // Hit!
> // Hit!
> // Hit!
> ```
>
> On Tue, Nov 10, 2015, 15:08 Gilbert B Garza 
> wrote:
>
> Normally yes, but since the pipeline operator is a pure function, I think
> it's possible for the compiler to optimize away the intermediate arrow
> functions. I mention this in the "Functions with Multiple Arguments"
> section https
> 
> ://
> 
> github.com
> 
> /
> 
> mindeavor
> 
> /
> 
> ES7-pipeline-operator#functions
> 
> -with-multiple-arguments
> 
>
>
> On Tue, Nov 10, 2015 at 12:52 PM, Isiah Meadows 
> wrote:
>
> Inline
>
> On Tue, Nov 10, 2015 at 12:52 PM, Kevin Smith 
> wrote:
> >> - I don't like the requirement to use the keyword `this` to compose
> >> functions. JS already has many features to support the keyword `this`:
> >> prototypes, method invocations, function binding, arrow functions, and
> >> probably others. I prefer a feature that assists the other side of the
> >> spectrum.
> >
> >
> > Yep - a well documented critique.  It depends on your point of view, I
> > think.  If you view these things as "extension methods", then using
> `this`
> > makes more sense.
> >
> >> - The fact that there are new semantics to what looks like a normal
> >> function call (e.g. `->map(...)`) doesn't set well with me. You could
> argue
> >> that it's something to get used to. Even in that case, I would expect
> the
> >> first argument I give to `map` to stay the first argument.
> >
> >
> > This is a reasonable objection, I think.
>
> Not to mention it's still a point of contention:
> https
> 
> ://
> 
> github.com
> 
> /
> 
> zenparsing
> 
> /
> 
> es-function-bind
> 
> /issues/26#issuecomment-154130932
> 
> (from here, down)
>
> >
> >> With the pipeline operator, partial application is left to the
> developer.
> >> They can choose to use arrow functions, or to curry their functions. I
> think
> >> this is the best option since it keeps things simple (no new
> semantics), and
> >> remains readable – see the "Function with Multiple Arguments" section
> in the
> >> GitHub link https 
> :// github.com
> /
> mindeavor
> /
> ES7-pipeline-operator
> 

Re: Generator getter method

[Bergi]

Mohsen Azimi schrieb:


I'm proposing to allow  `get corners* () { ...` (a generator getter
method) so the for..of loop can be written like this:

```
for (let corner of rectangle.corners) {
   console.log(corner);
}
```


I would avoid that. `rectangle.corners !== rectangle.corners` could be 
quite confusing. Creating the generator explicitly is a better idea.
And as kevin said, you still can return generators from your getters 
manually if you really want that.


Regards,
 Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator getter method

[Rick Waldron]

On Tue, Nov 10, 2015 at 2:28 PM Mohsen Azimi  wrote:

>
> for (let corner of rectangle.getCorners()) {
>   console.log(corner);
> }
> ```
>
> for (let corner of rectangle.corners) {
>   console.log(corner);
> }
> ```
>
> Which seems cleaner
>

Either could've been called "corners" and then the only difference is the
invocation parens.


Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Concise Method Binding

[Isiah Meadows]

It's using an ES7 proposal, and it's a method bound to the instance.

On Tue, Nov 10, 2015, 18:58 Rick Waldron  wrote:

> On Mon, Nov 9, 2015 at 8:45 PM JD Isaacks  wrote:
>
>> Considering the proposals for both concise methods and the bind operator
>> I think it would be a great addition to be able to use them together.
>>
>> I am already seeing a lot of this:
>>
>> class Foo {
>>   bar = () => {
>> // bound
>>   }
>>   buz() {
>> // unbound
>>   }
>> }
>>
>>
>>
> Can you clarify what this is, because it's not valid ES6 code. Also,
> "bound" and "unbound" in what sense? In `buz`, the `this` object will be
> the instance of Foo from which it's called.
>
> Rick
> ___
> 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: Look-behind proposal in trouble

[Erik Corry]

I made a playground where you can try out regexps with lookbehind.

https://dartpad.dartlang.org/8feea83c01ab767acdf1

On Tue, Oct 13, 2015 at 9:24 PM, Nozomu Katoo  wrote:

> Erik Corry wrote on Tue, 13 Oct 2015 at 11:18:48 +0200:
> > Yes, that makes sense.
> >
> > This could be fixed by removing {n} loops from positive lookbehinds.  Or
> by
> > doing the .NET-style back-references immediately.
>
> Personally, I am reluctant to remove any feature from the current
> proposal intentionally for a future proposal that it is uncertain
> whether it really comes or not. It might end up only making lookbehinds
> of ECMAScript and ones of Perl 5 incompatible.
>
> >> On 10/10/2015 03:48, Erik Corry wrote:
> >>
> >>>
> >>> On Sat, Oct 10, 2015 at 12:47 AM, Waldemar Horwat wrote:
> >>>
> >>> It's not a superset.  Captures would match differently.
> >>>
> >>>
> >>> Can you elaborate?  How would they be different?
> >>>
> >>
> >> If you have a capture inside a loop (controlled, say, by {n}), one of
> the
> >> proposals would capture the first instance, while the other proposal
> would
> >> capture the last instance.
>
> I was missing that point. I just confirmed that
>
>   perl -e "$a = 'abcdef'; $a =~ /(?<=.(.){2}.)./; print $1;"
>
> returned 'c' whereas .NET returned 'b'. Implementation based on my
> proposal would return the same result as Perl 5.
>
>
> By the way, at one point in this thread, I moved some email addresses
> from To to Cc when sending my reply. But somehow several of them had
> disappeared from the Cc field in the delivered email while they all
> remain in a copy in my sent-email folder. I apologize to those who
> received disconnected emails in this thread.
>
> Regards,
>   Nozomu
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Javascript Code Churn Rate?

[Nelo Mitranim]

In case you happen to be unaware, the V8 team recently came out with ideas 
about a “stricter mode” that cuts down on questionable features that hurt 
optimisation: https://developers.google.com/v8/experiments?hl=en, relevant HN 
discussion: https://news.ycombinator.com/item?id=9178765
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Concise Method Binding

[Rick Waldron]

On Tue, Nov 10, 2015 at 6:59 PM Isiah Meadows 
wrote:

> It's using an ES7 proposal, and it's a method bound to the instance.
>
Ah, right—that proposal does not have consensus:
https://github.com/rwaldron/tc39-notes/blob/master/es7/2015-09/sept-22.md#54-updates-on-class-properties-proposal
.

Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is \u006eew a valid Identifier?

[Eric Suen]

In Spec it's clear that escaped reservedWords is not Identifier nor ReservedWord

In 
https://esdiscuss.org/topic/fw-unicode-escape-sequences-for-keywords-what-s-the-correct-behaviour
you said it's keywords...
I said in Jave/C# escaped keywords is keywords, you said JavaScript is
not Java nor C#...

In https://code.google.com/p/google-caja/wiki/SecurityAdvisory20131121
"JavaScript parsers differ on whether they interpret escaped sequences
of letters spelling a reserved word, such as "de\u006Cete", as an
identifier or a reserved word." that may cause issue.

Till today still none Engine/Tool parse it correctly, Chrome/babel
treat it as Identifier, IE 11 and Firefox 42.0 and esprima treat it as
keywords.

It's confirm that escaped reservedWords is not Identifier. Can I have
a final conclusion is it keywords or not?

On Tue, Nov 10, 2015 at 1:05 AM, Allen Wirfs-Brock
 wrote:
>
> On Nov 9, 2015, at 6:55 AM, Andreas Rossberg  wrote:
>
> Allen, what was the motivation for allowing random escapes in
> identifiers but not in keywords? AFAICS, it would be simpler and more
> consistent to allow them anywhere and render "escape normalisation" a
> uniform prepass before tokenisation. IIUC, that's what other languages
> do. The current ES rules are far from ideal, and require jumping
> through extra hoops, in particular, to handle context-dependent
> keywords like `yield`.
>
> /Andreas
>
>
> see:
>
> Here are some references:
> https://github.com/tc39/tc39-notes/blob/master/es6/2013-11/nov-20.md#42-clarification-of-the-interaction-of-unicode-escapes-and-identification-syntax
> https://bugs.ecmascript.org/show_bug.cgi?id=277
> https://esdiscuss.org/topic/fw-unicode-escape-sequences-for-keywords-what-s-the-correct-behaviour
> https://esdiscuss.org/topic/this-vs-thi-u0073
>
> there are many others, and also there were earlier TC39 meeting discussions
> that I didn’t find in my quick search.
>
> It’s a usability vs. implementor convience trade-off.  the TC39 was to go
> with usability (and in particular readability).
>
> (Also, my recollection is that in some TC39 discussions (that I didn’t find
> in my search) there were security concerns raised WRT allowing unicode
> escapes in keywords. Probably concerns about code injection filters not
> recognizing escaped keywords)
>
> In ES6 (and I believe that Waldemar would claim in previous editions)
> unicode escapes cannot be handled with such a prepass. Essentially, escaped
> and non-escaped IdentifierName characters are only equated when doing
> identifier binding or property name lookups. It’s probably a misperception
> of the lexical grammar and static semantics that leads some implementors
> down the path of thinking that  such a preps is reasonable.
>
> Regarding `yield`, if it is written containing unicode escapes it is never a
> contextual keyword.
>
> BTW, personally I I would be just fine with never allowing unicode escapes
> within IdentiferName. But that would be a web breaking change.
>
> Allen
>
>



-- 

Spket IDE - Development Tool for RIA.

http://www.spket.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Javascript Code Churn Rate?

[Ethan Resnick]

I've been trying to think through possible ways to address JS's growing
complexity (something I know I'm not alone in worrying about) that are
consistent with "don't break the web". I understand going in that the
solution will largely lie in controlling future growth rather than removing
existing features, which will always be hard and is currently near
impossible. Still, I feel like deprecation/subsetting approaches might not
have been adequately explored.

Before I go on proposing things without knowing what I'm talking about,
though, I was hoping y'all could point me to (or help me by collecting?)
some relevant data. In particular, I'm wondering: what's the distribution
of the age of js files on the web, accounting for the frequency with which
each page is visited? Or, more concretely: suppose you could magically get
all new/newly-modified JS to only use a particular subset of the language;
how long would it take for that subset to dominate the web, such that
engines could heavily optimize for it? And how long until they could remove
support for the rest of the language altogether?

Cheers,
Ethan

P.S. Long time es-discuss lurker and I really admire all the great work you
folks do here.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Javascript Code Churn Rate?

[Ethan Resnick]

Thanks Nelo! Yes, I've seen strong mode and I think it's an interesting
idea (though it trades a bit more usability for performance than I would
have personally). Still though, I'm curious to see the js churn data if
anyone has it, as that effects all approaches in the strong mode vein.

On Tue, Nov 10, 2015 at 4:57 AM, Nelo Mitranim  wrote:

> In case you happen to be unaware, the V8 team recently came out with ideas
> about a “stricter mode” that cuts down on questionable features that hurt
> optimisation: https://developers.google.com/v8/experiments?hl=en,
> relevant HN discussion: https://news.ycombinator.com/item?id=9178765
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss