Re: JavaScript Versioning

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

Re: JavaScript Versioning

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

Re: JavaScript Versioning

(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

Re: JavaScript Versioning

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;

JavaScript Versioning

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

Add an easier method for slicing and stepping strings and arrays

I always found the Python methodology of selecting characters from strings (or items from arrays) to be the most natural I've found among a number of language solutions.  Was considering whether adding the syntax would be beneficial for JavaScript.  For those who do not know, the syntax is as

Re: Removal of language features

Jordan is right about this needing to be a more civil discussion. The hostile environment prevents people from even wanting to participate in the conversation, including myself. Above Steve mentions that many people are mixing language additions with framework fatigue. I have to agree with him.

Re: Removal of language features

Please note, "piss on them" is certainly achieved by your antagonistic comments about TC39's "bikeshedding" on two valuable recent proposals, which do solve real-world problems - even if they aren't your own. I'll withhold comment on the rest of the thread beyond a general comment to everyone

Re: Removal of language features

Some comments on various posts in this thread: 1. Asia has more than four billion people. Can we please avoid making generalizations about the level of competence of engineering managers in that region to make risk/benefit trade-offs? 2. I don't understand the TC39 process, but I am guessing

Re: Removal of language features

This makes sense to me. Though I kind of feel like the discussion has veered off on a less useful direction because of reactions to words like "policing" or "gatekeeping". It may be more productive to consider whether it might be useful to have a mechanism whereby frameworks could leverage the

Re: Removal of language features

On 07/21/2017 03:00 PM, kai zhu wrote: Can you produce any data at all to back that up? I've never seen any appetite in that regard at all. no hard data admittedly. i regularly attend tech meetups in hong kong. at these gatherings, the general sentiment from frontend developers is that

Re: Removal of language features

Typescript allows breaking changes, ES doesn't. Hence it would be an acceptable decision for ES to clash with an existing Typescript keyword and force Typescript to update accordingly. Typescript developers shouldn't be unprepared, and ES can continue on its path. None of this makes Typescript

Re: Re: What is the status of Weak References?

Thank you for the link, I'm glad to see that people have been making progress on it. On Fri, Jul 21, 2017 at 2:16 PM, Isiah Meadows wrote: > This is probably best asked/stated here: > https://github.com/tc39/proposal-weakrefs/ > - > > Isiah Meadows >

Re: Removal of language features

CSP to name one, but you picked 1% of my reply. On Sat, 22 Jul 2017 at 19:52, Claude Petit wrote: > “TC39 consider the usage of `eval` inappropriate for production” > > > > And what about dynamic code, expressions evaluation, ...? Who has wake up > one day and decided that

FW: Removal of language features

“TC39 consider the usage of `eval` inappropriate for production” And what about dynamic code, expressions evaluation, ...? Who has wake up one day and decided that nobody should use “eval” ? From: Andrea Giammarchi [mailto:andrea.giammar...@gmail.com] Sent: Saturday, July 22, 2017 1:44

Re: Removal of language features

answering to all questions here: > What problems would this address? It will give developers a clear indication of what's good and future proof and what's not so cool. MooTools and Prototype extending natives in all ways didn't translate into "cool, people like these methods, let's put them on

Re: Removal of language features

> On Jul 22, 2017, at 11:37 PM, Maggie Pint wrote: > > Having been a delegate to tc39 from the JS foundation for only about six > months, I can't claim authority to speak to all of the history here. That > said, I can very assuredly tell you there is a significant amount

Re: Removal of language features

Having been a delegate to tc39 from the JS foundation for only about six months, I can't claim authority to speak to all of the history here. That said, I can very assuredly tell you there is a significant amount of respect for every technology that has been mentioned in this thread from most of

Re: Removal of language features

On Jul 22, 2017 11:14 AM, "Andrea Giammarchi" wrote: About frameworks or Angular, version 1 was based on eval and I think frameworks should have an OK from TC39 before being considered influential . What problems would this address? I would prefer almost any

Re: Removal of language features

My point was that ES classes work as spec'd TypeScript classes are broken without warning. It's also not a matter of smelly instanceof, the problem is that if you add a method to that list class it won't be there. The returned instance/object won't have anything to do with the List class so

Re: Removal of language features

On Sat, Jul 22, 2017 at 3:17 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > ```js > class List extends Array { } > > console.log(new List instanceof List); > // false .. seriously > ``` > > Try it yourself. [1] > I don't have a horse in the TypeScript race, but that example is

Re: Removal of language features

My 2 cents > TypeScript, which like it or not is a perfectly well-defined language. TS these days is a broken, diverging, branch of latest ECMAScript features, IMO. ```js class List extends Array { } console.log(new List instanceof List); // false .. seriously ``` Try it yourself. [1] You

Re: Removal of language features

Inline. On Saturday, July 22, 2017 7:47:32 AM CEST Bob Myers wrote: > Let me weigh in as an Angular programmer. > > Angular does not "encourage use of non-standard and/or unstable language > features". It encourages (indeed for all practical purposes mandates) the > use of TypeScript, which like