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: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 19 Jul 2013 23:36:07 -0700
Message-ID: <CA+c2ei_aLJytGC9UeH7aY7+18GoNqB5XPCUXPh8ur-sBhO2CzA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
If we end up with something like the current filesystem API that Jan
and I has sent to the webapps list (I'll send an updated proposal to
this list once it's had time to get a bit more feedback), then it
would be terribly useful to have both of File.isFile() and

/ Jonas

On Fri, Jul 19, 2013 at 8:46 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> I've brought this up before: there is nothing in the DOM that allows
> reliably detecting DOM objects that implement a given interface. Something
> like Array.isArray or ArrayBuffer.isView as defined in ES.
> Last time this came up we had sort of agreed to make instanceof kinda work
> for this by making it consider brands in addition to proto chains, but this
> has a problem: HTMLElement.prototype instanceof Node is very much true (and
> web pages depend on this behavior, as I recall) but HTMLElement.prototype is
> most definitely not something that would pass a sane isNode() check...
> Now I suppose spec authors could add such things ad-hoc (e.g. add a "static
> boolean isNode(any arg)" on Node and define it in prose to return true if
> and only if arg is a Node).  But maybe there should be a way to either
> express this in IDL or the default behavior should be to have such methods?
> -Boris
Received on Saturday, 20 July 2013 06:37:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:17 UTC