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

On Fri, Sep 28, 2012 at 9:24 PM, Travis Leithead <
travis.leithead@microsoft.com> wrote:

>  I was alluding to this behavior for interface objects (e.g., “URL”):****
>
> ** **
>
> *4.4.1.1. 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.
>

Thanks, but this part I already very much understand, ie. non-constructors
will throw if an attempt is made to call them as a function, with or
without the new operator (call or construct, as the case may. 9.11, 11.2.2,
11.2.3, 13.2 of 262/ES5.1)

I wasn't specific enough in my original question, but I did note that I
wasn't referring to construction exceptions, so I'm guessing by your
response that you actually _just_ meant testing for "constructability". I
apologize for not being clearer, but I was actually referring to the URL
string parameter itself, and how to test if passing an argument to the
constructor is supported (the example I gave falls short of answering that
question).


Loosely related... will invalid URL string parameters throw in the same
manner that invalid selectors throw? eg. context.querySelector("?")


Rick




> ****
>
> ** **
>
> *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> 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 ****
>
> ** **
>
> Rick****
>
> ** **
>