W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: Maybe we should think about Interface.isInterface functions again

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 7 Aug 2013 16:06:48 +0100
Message-ID: <CADnb78j0KjxtrFxrXuHHRukAg9LVCRahQ7xRwHAYw0gcpypumg@mail.gmail.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
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 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.

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.


-- 
http://annevankesteren.nl/
Received on Wednesday, 7 August 2013 15:07:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC