It was pointed out to me that I forgot to include the latest slides for async generator. I was referring to the link included earlier in the thread. Sorry for the confusion.
Here is the link again. https://docs.google.com/a/netflix.com/file/d/0B4PVbLpUIdzoMDR5dWstRllXblU Dictated using voice recognition. Please forgive the typos. On Jun 12, 2014, at 10:57 AM, "Mark S. Miller" <[email protected]> wrote: Wow, what a mess. Let's forget the builtins for a moment and focus on JS classes, both the old/current patterns for coding these manually, and the new ES6 class syntax. Consider: class Point { constructor(x, y) { this.x = x; this.y = y; }, getX() { return this.x; }, getY() { return this.y; }, toString() { return `<${this.getX()},${this.getY()}>`; } } or equivalently enough in ES5 function Point(x, y) { this.x = x; this.y = y; } Point.prototype = { getX: function() { return this.x; }, getY: function() { return this.y; }, toString: function() { return '<' + this.getX() + ',' + this.getY() + '>'; } }; alert(Point.prototype) alerts "<undefined,undefined>". Ok, this specific example doesn't throw, but equally simple and plausible examples would. On Thu, Jun 12, 2014 at 5:26 AM, Till Schneidereit < [email protected]> wrote: > While working on changing Date.prototype to be a plain object in > SpiderMonkey, we realized that there's an issue: the way things are specced > now, `alert(Date.prototype)` will throw, because `Date.prototype.toString` > isn't generic. The same applies for all builtins with non-generic > `toString` prototype functions. > > To resolve this, I propose changing these `toString` to first check if the > `this` value is %FooPrototype% (e.g., %DatePrototype% in the case at hand) > and return the result of the equivalent of calling the original > Object.prototype.toString. > > I'm not sure if that is enough to cover subclasses of these builtins. Will > calling `toString` on the prototype of `class MyDate extends Date{}` still > throw? If so, that would at least not be a backwards-compatibility concern, > but it's probably also not desirable. > > > till > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
