Re: Error-Type Specific try/catch Blocks

TL;DR: I *really* want full pattern matching, but it's a very long and steep road to climb, and no one has gotten it right yet in a dynamic language [1]. None of the implementors will be okay with it until you demonstrate that it's both possible and practical to implement, with minimal memory and

Re: Error-Type Specific try/catch Blocks

Hmmm, can't find your proposal, mind to share the link directly? I did however find a comment from Brendan Eich 3 years ago that basically resonated with my idea that refutable patterns and matching is the way to go for conditional catch, and another thread from a year ago that this still is the

Re: Tracking proposals should be standardized with issues

> On May 13, 2016, at 10:02 PM, Bob Myers wrote: > > This entire process is quite unfriendly to grassroots proposals and I hope it > can be tweaked. > > > All proposals that are officially considered by TC39 have to have been > > submitted in conformance with the Ecma IPR

Re: extending an ES6 class using ES5 syntax?

Good call, however, it wouldn't work so well with constructor because `Object.setPrototypeOf(B, A)` is still neede here, and also trashing initial `B.prototype` with an all enumerable assignment still wouldn't solve this case. ```js B.prototype = { __proto__: A.prototype, constructor: B, //

Re: extending an ES6 class using ES5 syntax?

On Sun, May 15, 2016 at 6:23 PM, Rob Brackett wrote: > > I'm trying to provide a path where common code can migrate to ES6 > classes before all the consumers have. So I was really looking for > something that didn't require the subclasses to be touched at all (I wasn't >

Re: Error-Type Specific try/catch Blocks

Pattern matching has been considered before, and the performance will suck if you consider things like `Point(x, y)`. It's very hard to optimize at runtime, and engines don't have time to optimize that statically. If you want to consider Clojure as an example of one that does this dynamically, it

Re: operator overloading proposal

If both have the operator, the left side would be used (I thought I said that, but I may have not). I'm thinking, instead, static methods should be used. It would be more versatile. ```js class Vec2 { constructor(x, y) { this.x = x this.y = y } // `this` and `Vec2`

Re: extending an ES6 class using ES5 syntax?

> On May 16, 2016, at 10:31 AM, Jason Orendorff > wrote: > > ... > `B.prototype = Object.create(A.prototype)` is less of a problem, for > our implementation, because objects created by constructor B later get > a prototype chain where every object is clean (none of

Re: extending an ES6 class using ES5 syntax?

In short, cache invalidation is hard. Standard disclaimer: everything below is a radical simplification of what really goes on in a JS engine... When a property access (or equivalently, a method call) happens, the standard says to do a lookup along the prototype chain to find out where the

Re: extending an ES6 class using ES5 syntax?

It's funny, if you think that the entire story of `__proto__` is because Zepto library was using and not willing to ditch the conversion of `document.querySelectorAll('css')` results as `Array` via `__proto__` ... and only because that was way faster than an

Re: extending an ES6 class using ES5 syntax?

On Sun, May 15, 2016 at 3:07 AM, Andrea Giammarchi wrote: > Thanks Andy, I think that bug has exact same concerns and valid answers for > Boris too. Here it's also the only valid option to properly extend classes > in ES5 and I can't wait for such "warning" to go