Re: Removal of language features

[Isiah Meadows]

Thought I'd clarify why I brought TypeScript in from:

- TypeScript in of itself is *not* a problem.
- Angular's use and embrace of TypeScript in of itself is *not* a problem.
- TypeScript was more of a tangentially related side detail.

I was only referring to Angular embracing a stage 2 proposal,
specifically decorators (with TypeScript extensions thereof), that had
become rather unstable a few months before they went beta with v2.0.
It's a technical risk taken by a framework with already very high
usage, one that introduced significant technical debt, and one I
questioned from the start.

(I could understand if it were stage 3, gaining browser support. But
to be clear, a year ago when they made the decision, it was a poor
choice, being relatively new and immature for a stage 2 proposal.)

-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[kdex]

This was kind of the original idea around Dart IIRC. It didn't see much 
traction though, and eventually got called off.

On Monday, July 24, 2017 1:56:53 AM CEST doodad-js Admin wrote:
> And more, engines could signal they support JS 2 just by the Accept header!
> 
> -Original Message-
> From: David White [mailto:david.rhys.wh...@icloud.com]
> Sent: Sunday, July 23, 2017 7:52 PM
> To: doodad-js Admin 
> Cc: es-discuss@mozilla.org
> Subject: Re: Removal of language features
> 
> Ooooh, a mime type based versioning would be very nice!
> 
> ``
> 
> For the most part you control your applications language decision and honour
> that with your bundle then load additional scripts you have little control
> over such as logging, monitoring, stats, etc in different runtimes perhaps.
> 
> It’s certainly cleaner than injecting a version into the top of your bundle
> and would allow 3rd party vendors to provide version specific bundles.
> 
> David
> 
> > On 24 Jul 2017, at 00:43, doodad-js Admin  wrote:
> > 
> > May I propose a new file extension and mime-type... "js2":
> > "application/javascript.2" ?
> > 
> > -Original Message-
> > From: David White [mailto:david.rhys.wh...@icloud.com]
> > Sent: Sunday, July 23, 2017 7:35 PM
> > To: doodad-js Admin 
> > Subject: Re: Removal of language features
> > 
> > That’s an interesting proposal but I’m struggling to think how that would
> > solve this same issue 2 or 3 or 5 years down the line? JavaScript and
> > browsers have a symmetry along with HTML, CSS... and given the disparity
> > of devices today alone, let alone tomorrow a new major version would
> > cause more harm than good. Ideally we would need a solution that works as
> > ES5 as standard, then have that semantic in later versions of the
> > language.
> > 
> > Perhaps this is not a problem for this community but something browser
> > providers should be providing / considering to allow developers to
> > specify their runtime in order to allow the language to progress more
> > natrurally?
> > 
> > David
> > 
> >> On 23 Jul 2017, at 23:38, doodad-js Admin  wrote:
> >> 
> >> Maybe that's time to start a new major version of JS?
> >> 
> >> -Original Message-
> >> From: David White [mailto:david.rhys.wh...@icloud.com]
> >> Sent: Sunday, July 23, 2017 5:54 PM
> >> To: es-discuss@mozilla.org
> >> Subject: Re: Re: Removal of language features
> >> 
> >> Lots of good thoughts and discussions here, and while it’s gone slightly
> >> off topic I’d love to discuss the possibilities of how we could get
> >> JavaScript to a point where we could actively remove features with every
> >> new specification.
> >> 
> >> I’m sure nobody would want to break the web, which would be very likely
> >> removing any parts of JavaScript, and certainly the biggest challenge,
> >> it does seem a shame that we can’t find an ulterior direction as it does
> >> seem allowing various features we consider bad practice today to still
> >> exist and the overhead that exists with them certainly hinders progress
> >> more than it helps.
> >> 
> >> Linting is certainly the fastest and easiest method, but to a certain
> >> extent I not really a solution in that we only lint our own code, and
> >> not the additional code that we rely upon. Ideally removal of features
> >> should mean more performance out of JavaScript, if engines have less
> >> constructs to deal with then there should be some beneficial performance
> >> related with that?
> >> 
> >> Given the lack of control over what browsers many users are using perhaps
> >> versioning could be a new semantic built into the language itself in the
> >> same way we have strict mode?
> >> 
> >> We could allow developers the option to specify the version they wish to
> >> use, avoiding unnecessary transpiration back to ES5 for applications
> >> confident enough to give their users the choice to upgrade if needed but
> >> also allow browsers to only run based on versions?
> >> 
> >> I'm sure it’s worth considering as removing features of a language /
> >> application is as important, if not more so, than adding features to a
> >> language or application.
> >> 
> >> David
> > 
> > ---
> > This email has been checked for viruses by AVG.
> > http://www.avg.com
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

signature.asc
Description: This is a digitally signed message part.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Inline variable dereferencing of object field names

[Logan Smyth]

Assuming in your first example you meant

query.$pull[team] = userId;

not

query[team] = userId;

then your second example is already valid a ES6 computed property and does
exactly what you appear to be looking for.

On Sun, Jul 23, 2017 at 8:15 PM, Sebastian Malton 
wrote:

> When creating objects I think that having some notation to make the
> following easier to read
>
> let query = {
> $pull: {}
> };
> query[team] = userId;
>
> I was thinking of borrowing from the above notation and doing the
> following:
>
> let query = {
> $pull: {
> [team]: userId
> }
> };
>
> ___
> 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

Inline variable dereferencing of object field names

[Sebastian Malton]

 When creating objects I think that having some notation to make the following easier to readlet query = {    $pull: {}};query[team] = userId;I was thinking of borrowing from the above notation and doing the following:let query = {    $pull: {        [team]: userId    }};  ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

FW: Removal of language features

[doodad-js Admin]

I'm dealing with 4 emails, so sometimes I don't select the good one and get 
rejected by es-discuss :) This is my latest email...

Claude Petit

-Original Message-
From: Claude Petit [mailto:p...@webmail.us] 
Sent: Sunday, July 23, 2017 8:01 PM
To: 'doodad-js Admin' ; 'David White' 

Cc: es-discuss@mozilla.org
Subject: RE: Removal of language features

Sorry, I'm very sorry... I mean "clients", not "engines".

Claude Petit

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

Re: Re: JavaScript Versioning

[David White]

Sorry, just seen this thread and thought it worth mentioning a similar thread 
ongoing here that has derived from wanting to remove less popular features from 
the specification:

https://esdiscuss.org/topic/removal-of-language-features

We should definitely continue this conversation in this thread.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[David White]

Ooooh, a mime type based versioning would be very nice!

``

For the most part you control your applications language decision and honour 
that with your bundle then load additional scripts you have little control over 
such as logging, monitoring, stats, etc in different runtimes perhaps.

It’s certainly cleaner than injecting a version into the top of your bundle and 
would allow 3rd party vendors to provide version specific bundles.

David

> On 24 Jul 2017, at 00:43, doodad-js Admin  wrote:
> 
> May I propose a new file extension and mime-type... "js2": 
> "application/javascript.2" ?
> 
> -Original Message-
> From: David White [mailto:david.rhys.wh...@icloud.com] 
> Sent: Sunday, July 23, 2017 7:35 PM
> To: doodad-js Admin 
> Subject: Re: Removal of language features
> 
> That’s an interesting proposal but I’m struggling to think how that would 
> solve this same issue 2 or 3 or 5 years down the line? JavaScript and 
> browsers have a symmetry along with HTML, CSS... and given the disparity of 
> devices today alone, let alone tomorrow a new major version would cause more 
> harm than good. Ideally we would need a solution that works as ES5 as 
> standard, then have that semantic in later versions of the language.
> 
> Perhaps this is not a problem for this community but something browser 
> providers should be providing / considering to allow developers to specify 
> their runtime in order to allow the language to progress more natrurally?
> 
> David
> 
> 
>> On 23 Jul 2017, at 23:38, doodad-js Admin  wrote:
>> 
>> Maybe that's time to start a new major version of JS?
>> 
>> -Original Message-
>> From: David White [mailto:david.rhys.wh...@icloud.com] 
>> Sent: Sunday, July 23, 2017 5:54 PM
>> To: es-discuss@mozilla.org
>> Subject: Re: Re: Removal of language features
>> 
>> Lots of good thoughts and discussions here, and while it’s gone slightly off 
>> topic I’d love to discuss the possibilities of how we could get JavaScript 
>> to a point where we could actively remove features with every new 
>> specification.
>> 
>> I’m sure nobody would want to break the web, which would be very likely 
>> removing any parts of JavaScript, and certainly the biggest challenge, it 
>> does seem a shame that we can’t find an ulterior direction as it does seem 
>> allowing various features we consider bad practice today to still exist and 
>> the overhead that exists with them certainly hinders progress more than it 
>> helps.
>> 
>> Linting is certainly the fastest and easiest method, but to a certain extent 
>> I not really a solution in that we only lint our own code, and not the 
>> additional code that we rely upon. Ideally removal of features should mean 
>> more performance out of JavaScript, if engines have less constructs to deal 
>> with then there should be some beneficial performance related with that?
>> 
>> Given the lack of control over what browsers many users are using perhaps 
>> versioning could be a new semantic built into the language itself in the 
>> same way we have strict mode?
>> 
>> We could allow developers the option to specify the version they wish to 
>> use, avoiding unnecessary transpiration back to ES5 for applications 
>> confident enough to give their users the choice to upgrade if needed but 
>> also allow browsers to only run based on versions?
>> 
>> I'm sure it’s worth considering as removing features of a language / 
>> application is as important, if not more so, than adding features to a 
>> language or application.
>> 
>> David
>> 
> 
> 
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
> 
> 

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

Re: JavaScript Versioning

[kai zhu]

> > The bottom line here is that browsers aren't a place for a type safe and
> > correct language (well, thy could have been but hey, such is history).
> > They're a medium to consume information over the internet.

due to history, the hard-reality is that its impractical to write
completely correct frontend-code because there are simply too many UX
edge-cases to account for.  this inconvenient truth bites non-frontend
engineers everytime they try to write a "correct" browser program, and get
overwhelmed by the scope of such a requirement.  angular2 is a texbook
example of sacrificing convenience (of angular1) for the sake of more
correctness.
On Jul 24, 2017 6:11 AM, "kdex"  wrote:

> For the sake of keeping our discussions clear, could we all please refrain
> from flooding the entire mailing list's inbox with these unsubstantial
> "+1" or
> "-1" emails if they contain no meaningful contribution to the conversation?
>
> If you want to make a point, make your point. If not, don't.
>
> Much obliged!
>
> On Sunday, July 23, 2017 11:58:34 PM CEST kai zhu wrote:
> > > On Jul 23, 2017, at 4:47 PM, Dante Federici <
> c.dante.feder...@gmail.com>
> > > wrote:
> > >
> > > The bottom line here is that browsers aren't a place for a type safe
> and
> > > correct language (well, thy could have been but hey, such is history).
> > > They're a medium to consume information over the internet.
> > +1
> ___
> 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: Removal of language features

[David White]

That’s an interesting proposal but I’m struggling to think how that would solve 
this same issue 2 or 3 or 5 years down the line? JavaScript and browsers have a 
symmetry along with HTML, CSS... and given the disparity of devices today 
alone, let alone tomorrow a new major version would cause more harm than good. 
Ideally we would need a solution that works as ES5 as standard, then have that 
semantic in later versions of the language.

Perhaps this is not a problem for this community but something browser 
providers should be providing / considering to allow developers to specify 
their runtime in order to allow the language to progress more natrurally?

> On 23 Jul 2017, at 23:38, doodad-js Admin  wrote:
> 
> Maybe that's time to start a new major version of JS?
> 
> -Original Message-
> From: David White [mailto:david.rhys.wh...@icloud.com] 
> Sent: Sunday, July 23, 2017 5:54 PM
> To: es-discuss@mozilla.org
> Subject: Re: Re: Removal of language features
> 
> Lots of good thoughts and discussions here, and while it’s gone slightly off 
> topic I’d love to discuss the possibilities of how we could get JavaScript to 
> a point where we could actively remove features with every new specification.
> 
> I’m sure nobody would want to break the web, which would be very likely 
> removing any parts of JavaScript, and certainly the biggest challenge, it 
> does seem a shame that we can’t find an ulterior direction as it does seem 
> allowing various features we consider bad practice today to still exist and 
> the overhead that exists with them certainly hinders progress more than it 
> helps.
> 
> Linting is certainly the fastest and easiest method, but to a certain extent 
> I not really a solution in that we only lint our own code, and not the 
> additional code that we rely upon. Ideally removal of features should mean 
> more performance out of JavaScript, if engines have less constructs to deal 
> with then there should be some beneficial performance related with that?
> 
> Given the lack of control over what browsers many users are using perhaps 
> versioning could be a new semantic built into the language itself in the same 
> way we have strict mode?
> 
> We could allow developers the option to specify the version they wish to use, 
> avoiding unnecessary transpiration back to ES5 for applications confident 
> enough to give their users the choice to upgrade if needed but also allow 
> browsers to only run based on versions?
> 
> I'm sure it’s worth considering as removing features of a language / 
> application is as important, if not more so, than adding features to a 
> language or application.
> 
> David
> 

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

RE: Removal of language features

[doodad-js Admin]

To be honest, I started my own framework because of the lack of classical oop 
and a clear type system in JS. I know TypeScript, but that’s another language, 
not just a framework like mine. After that, ES6 classes has come to the 
surface, but they do not respond to my needs, and some choices on their 
behavior are not convenient. I’m waiting for new proposals like public/private 
fields and decorators, but just for the purpose of transpiling my classes to 
those of ES6 the most than possible for performance. I don’t think to have 
enough influence to get my classes system reflected in JS :)

 

From: kai zhu [mailto:kaizhu...@gmail.com] 
Sent: Sunday, July 23, 2017 6:36 PM
To: Vinnymac 
Cc: Jordan Harband ; Claude Petit ; 
es-discuss 
Subject: Re: Removal of language features

 

 

On Jul 23, 2017, at 10:58 AM, Vinnymac  > wrote:

 

Above Steve mentions that many people are mixing language additions with 
framework fatigue. I have to agree with him. In my case I am not overwhelmed by 
any of the additions TC39 has chosen to make to ECMA. In fact it is something I 
look forward to each year now that things seem to be iterating at a faster 
rate. 

 

-1

strongly disagree.  the explosion of different frameworks is encouraged by the 
current unstable nature of ecmascript.  the phenomenon wouldn't have been so 
severe if there wasn’t the mindset that ecmascript is undergoing a "language 
revolution", and everyone had to write their own framework to adapt to it.

 

It feels more mature, and we can already do so much more than we ever could 
just a couple of years ago.

 

-1

in the end-goal of browser UX capabilities, i feel the latest batch of 
frameworks don’t add anything more capable than the older simpler ones.  they 
simply employ more complicated procedures to achieve the final desired UX 
feature.

 

i feel the commercial web-industry is now more wanting on guidance to reliably 
ship and maintain products. the views of some people that ecmascript should 
further expand and develop new ideas, hardly helps in this regard.

 


 

 

Virus-free.  

 www.avg.com 

 

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

RE: Re: Removal of language features

[doodad-js Admin]

Maybe that's time to start a new major version of JS?

-Original Message-
From: David White [mailto:david.rhys.wh...@icloud.com] 
Sent: Sunday, July 23, 2017 5:54 PM
To: es-discuss@mozilla.org
Subject: Re: Re: Removal of language features

Lots of good thoughts and discussions here, and while it’s gone slightly off 
topic I’d love to discuss the possibilities of how we could get JavaScript to a 
point where we could actively remove features with every new specification.

I’m sure nobody would want to break the web, which would be very likely 
removing any parts of JavaScript, and certainly the biggest challenge, it does 
seem a shame that we can’t find an ulterior direction as it does seem allowing 
various features we consider bad practice today to still exist and the overhead 
that exists with them certainly hinders progress more than it helps.

Linting is certainly the fastest and easiest method, but to a certain extent I 
not really a solution in that we only lint our own code, and not the additional 
code that we rely upon. Ideally removal of features should mean more 
performance out of JavaScript, if engines have less constructs to deal with 
then there should be some beneficial performance related with that?

Given the lack of control over what browsers many users are using perhaps 
versioning could be a new semantic built into the language itself in the same 
way we have strict mode?

We could allow developers the option to specify the version they wish to use, 
avoiding unnecessary transpiration back to ES5 for applications confident 
enough to give their users the choice to upgrade if needed but also allow 
browsers to only run based on versions?

I'm sure it’s worth considering as removing features of a language / 
application is as important, if not more so, than adding features to a language 
or application.

David

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

Re: Removal of language features

[kai zhu]

> On Jul 23, 2017, at 10:58 AM, Vinnymac  wrote:
> 
> Above Steve mentions that many people are mixing language additions with 
> framework fatigue. I have to agree with him. In my case I am not overwhelmed 
> by any of the additions TC39 has chosen to make to ECMA. In fact it is 
> something I look forward to each year now that things seem to be iterating at 
> a faster rate. 


-1
strongly disagree.  the explosion of different frameworks is encouraged by the 
current unstable nature of ecmascript.  the phenomenon wouldn't have been so 
severe if there wasn’t the mindset that ecmascript is undergoing a "language 
revolution", and everyone had to write their own framework to adapt to it.

> It feels more mature, and we can already do so much more than we ever could 
> just a couple of years ago.

-1
in the end-goal of browser UX capabilities, i feel the latest batch of 
frameworks don’t add anything more capable than the older simpler ones.  they 
simply employ more complicated procedures to achieve the final desired UX 
feature.

i feel the commercial web-industry is now more wanting on guidance to reliably 
ship and maintain products. the views of some people that ecmascript should 
further expand and develop new ideas, hardly helps in this regard.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

[kdex]

For the sake of keeping our discussions clear, could we all please refrain 
from flooding the entire mailing list's inbox with these unsubstantial "+1" or 
"-1" emails if they contain no meaningful contribution to the conversation?

If you want to make a point, make your point. If not, don't.

Much obliged!

On Sunday, July 23, 2017 11:58:34 PM CEST kai zhu wrote:
> > On Jul 23, 2017, at 4:47 PM, Dante Federici 
> > wrote:
> > 
> > The bottom line here is that browsers aren't a place for a type safe and
> > correct language (well, thy could have been but hey, such is history).
> > They're a medium to consume information over the internet.
> +1

signature.asc
Description: This is a digitally signed message part.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

[kai zhu]

> On Jul 23, 2017, at 4:47 PM, Dante Federici  
> wrote:
> 
> The bottom line here is that browsers aren't a place for a type safe and 
> correct language (well, thy could have been but hey, such is history). 
> They're a medium to consume information over the internet.

+1

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

Re: Return value of forEach

[Naveen Chawla]

Does anybody have any opinion on a new Array.prototype.each method that
does the same as forEach but returns the array, thereby allowing chaining
with sort, map, filter etc., while also preserving backwards compatibility?

On Sat, 8 Jul 2017, 1:08 p.m. T.J. Crowder, 
wrote:

> On Sat, Jul 8, 2017 at 1:40 AM, Michael J. Ryan 
> wrote:
>
>> Woudn't Array.prototype.all satisfy those use cases, they run until a
>> falsy value is returned.
>>
>
> Is there an `Array.prototype.all` proposal? I'm not seeing it on github.
> If you're thinking of `every` and `some`, they don't return a reference to
> the array, which seemed to be important to Naveen for chaining.
>
> -- T.J. Crowder
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: JavaScript Versioning

[Dante Federici]

A few times now you've proposed a "use _x_" syntax to achieve breaking
changes to the language.

"use strict" is more an attempt to condense the language and take a first
pass best practice. Not a means of "versioning" JS.

The bottom line here is that browsers aren't a place for a type safe and
correct language (well, thy could have been but hey, such is history).
They're a medium to consume information over the internet. Versioning would
be awesome and great, but there's always the "I don't want to leave X in
the dust" use case that needs to be considered.

"use strict" doesn't leave them high and dry, but does push the web to a
better place.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[T.J. Crowder]

Massive +1 on Jordan's call for increased civility and cleaner language.

On Sun, Jul 23, 2017 at 3:58 AM, Vinnymac  wrote:

> Above Steve mentions that many people are mixing language additions
> with framework fatigue. I have to agree with him. In my case I am not
> overwhelmed by any of the additions TC39 has chosen to make to ECMA.

Absolutely. Framework fatigue? Yes. Language change fatigue? Not at
all. The opposite, if anything -- eagerness to get to using the new
stuff.

> I don't think TC39 should need to babysit or have a special line of 
> communication with any specific libraries. Smells of lobbying and politics.

Yes indeed. Similarly:

On Sat, Jul 22, 2017 at 4:14 PM, Andrea Giammarchi
 wrote:

> TBH, I'd love to have an official review channel for hacky practices used on 
> frameworks, no matter how big is their company size, and flag officially as 
> TC39 friendly.

Same problem (lobbying and politics), as well as scope creep (that's
not their job) and limited resources (I'd rather they spent their TC39
time on the main mission: moving the language foward).

On Sat, Jul 22, 2017 at 6:44 PM, Andrea Giammarchi
 wrote
(replying to kai zhu ):

> > tc39 should be a bit more [expletive deleted] imo.
>
> No it shouldn't, it should be open minded and able to listen too.

Amen.

> However, when TC39 makes a decision the JS community follows quite 
> religiously that decision.
>
> If TC39 says everything is fine, you have today situation you describe.

I haven't seen any indiction from TC39 that using Stage 1 proposals in
production is "fine."

> If TC39 would give some little extra direction, you'd have people thinking 
> about what they're using daily, example:
>
> statement: TC39 considers Stage 1 unstable and it should never be used on 
> production.
>
> result: people using early transpilers cannot complain about anything about 
> it and it's their choice.
>
> statement: TC39 consider the usage of `eval` inappropriate for production
>
> result: people using any library fully based on eval or Function would start 
> looking for better options

I wouldn't have thought such statements were required, given the way
the stages are described in the [process
document](https://tc39.github.io/process-document/). Reading through
that, if you're relying on anything that isn't at least at Stage 4 or
*well* into Stage 3, you should know that it could change
significantly or go away entirely, and be prepared for that. Caveat
usor.

But sure, perhaps a "guidelines for use in production" section would
be useful. The people who are relying on Stage 1 stuff presumably
haven't read the process document anyway and so won't see the
guidelines, but having them there makes it easier for people to point
out to them the dangers (or at least, considerations) of what they're
doing, backed by a link to the document. E.g., that if they want to
use X, that's their choice, but they should be aware they'll probably
have to refactor at some point, perhaps repeatedly, as it evolves into
something stable.

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Add an easier method for slicing and stepping strings and arrays

[Dante Federici]

This feels like an attempt to get toward python's style of slice
. Which
I'm not opposed to, and would like to hear how it's better than just the
method.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Add an easier method for slicing and stepping strings and arrays

[Darien Valentine]

Here are some related threads from the past:

https://esdiscuss.org/topic/negative-indices-for-arrays
https://esdiscuss.org/topic/array-slice-syntax
https://esdiscuss.org/topic/javascript-language-feature-idea

I think I’ve seen it mentioned a few other times too.

The `arr[-1]` syntax is a non-starter I’m afraid, cause it’s just property
access. An array can already have a property with the key "-1".

Personally I’d find it weird for slicing to be singled out for special
syntax. It’s just a method. However I’d agree that it’s quite awkward to do
things like `arr[arr.length - 1]` or `arr.slice().pop()` etc to access from
the right. I think in one of those threads someone proposed a method like
`Array.prototype.nth()` which would accept negative indices, though this
creates an odd asymmetry since (presumably) we would not want to use -0 for
the last index.

In general I think the functionality you’re describing could be useful but
that it could be served better by adding methods rather than syntax.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

[Jordan Harband]

I don't think a new mode is a good idea.

On Sat, Jul 22, 2017 at 10:36 PM, Alexander Craggs <
alexan...@debenclipper.com> wrote:

> Huh, in which case I will!
>
> What are your thoughts on the non-error message part of this proposal?
>
> On 23/07/2017 06:34:48, Jordan Harband  wrote:
> Error messages 1) are unspecified, 2) change all the time, 3) vary by
> language, 4) vary across browser/engine implementations. There is zero
> reason that any error message couldn't be changed, and in fact, many
> browsers do improve them over time.
>
> I'd say before believing it can't be done, try filing tickets on Chromium,
> Webkit, SpiderMonkey, and Chakra, and see what the response is - you may
> get a more favorable response than you think.
>
> On Sat, Jul 22, 2017 at 10:19 PM, Alexander Craggs <
> alexan...@debenclipper.com> wrote:
>
>> *(Apologies for the double email Jordan, I accidentally replied to just
>> you, not es-discuss as well.  I'm new to this whole mailing list thing.)*
>>
>> Apologies, that was a bad example.  I was more considering "use strict"
>> to be breaking in the sense that some things that worked without it would
>> no longer work with it.  That doesn't match the current scenario at all.
>>
>> In terms of other threads giving reasons why no new modes were likely to
>> be introduced, most that I could find appeared to fail in the sense of the
>> content they provided, installing rules that were better found in a linter,
>> as opposed to a parsing mode.  Do you have any points on why the idea
>> itself is unlikely to be implemented as opposed to the content?
>>
>> I also feel that it is *impossible* for vendors to add such changes to
>> make error messages more useful because in the JavaScript syntax specified
>> ten years ago "await" didn't exist and it would just be an unexpected
>> string.  We would have to add some new detection feature for this newer
>> flavour to allow better messages.
>>
>> But error messages were the lowest suggestion for this new functionality,
>> and probably another bad example.  Just consider the hundreds of previously
>> rejected proposals that were very promising but couldn't be used because of
>> breaking backwards compatability.
>>
>> On 23/07/2017 05:50:31, Jordan Harband  wrote:
>> Strict mode wasn't a breaking change; browsers that don't understand
>> strict mode simply ignore the no-op string.
>>
>> There's lots of other threads on why no new modes are likely to ever be
>> introduced.
>>
>> There's also no need to add pragmas or make breaking changes to make
>> error messages more useful; for that, I suggest filing specific suggestions
>> on each engine vendor's bug tracker.
>>
>> On Sat, Jul 22, 2017 at 9:30 PM, Alexander Craggs <
>> alexan...@debenclipper.com> wrote:
>>
>>> One of the main issues I've found with why a significant number of
>>> proposals are rejected is because it would introduce breaking changes into
>>> JavaScript, a language created over 22 years ago.  It doesn't surprise me
>>> that people have suggestions to improve JavaScript that are breaking,
>>> popular syntax seems to have changed significantly in those years.
>>>
>>> We *did* introduce some breaking changes though, using the "use strict"
>>> header at the top of files.  Would it not make sense to introduce new
>>> breaking changes under a similar header for each change we suggest?  For
>>> example, "use es7" could allow people to say they are using the latest
>>> features.
>>>
>>> Say we create such versioning, it would allow us to improve the language
>>> so much more than we're currently able to, we'd no longer have to stick
>>> with useless error messages for forgetting `async`:
>>>
>>> ```js
>>> < function u() { let x = await "hi" }
>>> > Uncaught SyntaxError: Unexpected string
>>> // Now...
>>> < "use es7";
>>> < function u() { let x = await "hi" }
>>> > Uncaught SomeError: "await" keyword used outside of async function
>>> ```
>>>
>>> ___
>>> 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