W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

RE: In WebIDL, should having a .prototype on interface objects be optional?

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Sat, 29 Sep 2012 04:24:48 +0000
To: Rick Waldron <waldron.rick@gmail.com>, Cameron McCormack <cam@mcc.id.au>
CC: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>, public-webapps <public-webapps@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B383847D6ED@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
I was alluding to this behavior for interface objects (e.g., "URL"): Interface object [[Call]] method <http://dev.w3.org/2006/webapi/WebIDL/#es-interface-call>
If the interface<http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface> is declared with a [Constructor]<http://dev.w3.org/2006/webapi/WebIDL/#Constructor> extended attribute<http://dev.w3.org/2006/webapi/WebIDL/#dfn-extended-attribute>, then the interface object<http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object> can be called as a function to create an object that implements that interface. Interfaces that do not have a constructor will throw an exception when called as a function.
..."not supported" just means "URL is not a constructor/won't parse a URL string parameter". As Cameron noted, it's not an idea test-in the instance you note in Chome, that's due to the subtle difference in implementation of WebIDL per the above requirement.

From: Rick Waldron [mailto:waldron.rick@gmail.com]
Sent: Friday, September 28, 2012 4:24 PM
To: Cameron McCormack
Cc: Travis Leithead; Boris Zbarsky; public-script-coord@w3.org; public-webapps
Subject: Re: In WebIDL, should having a .prototype on interface objects be optional?

On Fri, Sep 28, 2012 at 4:14 PM, Cameron McCormack <cam@mcc.id.au<mailto:cam@mcc.id.au>> wrote:
Travis Leithead:
I guess you'd check for URL.href then? Or try { new URL("/test"); } catch (ex) { console.log("not supported"); }

I agree with Travis, you should be checking the particular features you want to use, rather than checking the existence of the prototype as a proxy for that test.

If URL.prototype was required to exist, you could just do ("href" in URL.prototype).  Since it currently doesn't, you could do ("href" in (URL.prototype || {})).

I'm interested in knowing more about what would throw. If URL is not a constructor function, it will throw, but if it is what aspect of the above would be "not supported". I ask because currently Chrome's URL (webkitURL) can construct, but it constructs a fairly useless instance and throws nothing (new webkitURL("/test");)

Thanks in advance

Received on Saturday, 29 September 2012 04:25:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:38 UTC