- From: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Date: Wed, 7 Aug 2013 11:57:05 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>, Domenic Denicola <domenic@domenicdenicola.com>, Travis Leithead <travis.leithead@microsoft.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Aug 7, 2013, at 8:06 AM, Anne van Kesteren wrote: > On Mon, Aug 5, 2013 at 4:48 PM, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote: >> We can't prevent people from writing poor code, but we don't have to be an enabler of it. > > As I understand things, part of the goal of TC39 is to be able to > explain the platform in terms of JavaScript. Currently the platform > has a ton of these identity checks. "Is /x/ a node", "is /x/ an > element", etc. We should be able to explain those and I hope that > symbols are going to give us that, although it will depend on the > specifics I suppose. Actually, for ES6 it's looking like WeakArray is going to be your best bet for cases where such tests where the branding really needs to be unforgeable. > > Not having those in script might make developer-written library code > more brittle. E.g. I get an untrusted array that I want to filter for > elements to process further. There's no way to distinguish between > element instances and prototype objects. And so code down the road > might invoke a method and get a TypeError because it was invoked on > something that's not an instance. Why is this a problem. Why would anybody intentionally add such a prototype object to such an array? Why is it good economics to do real runtime work to filter out the very unlikely occurrence of such values? Finally, if you want to ignore such bugs, why not just wrap your code with an exception-eating handler? Allen
Received on Wednesday, 7 August 2013 18:57:41 UTC