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

2012-10-01 Thread Rick Waldron
On Mon, Oct 1, 2012 at 10:58 AM, Travis Leithead < travis.leith...@microsoft.com> wrote: > From: Rick Waldron [mailto:waldron.r...@gmail.com] > > > > 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 > res

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

2012-10-01 Thread Travis Leithead
From: Rick Waldron [mailto:waldron.r...@gmail.com] > > 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 b

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

2012-09-29 Thread Rick Waldron
** ** > > *From:* Rick Waldron [mailto:waldron.r...@gmail.com] > *Sent:* Friday, September 28, 2012 4:24 PM > *To:* Cameron McCormack > *Cc:* Travis Leithead; Boris Zbarsky; public-script-co...@w3.org; > public-webapps > *Subject:* Re: In WebIDL, should having a .prototype on interface

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

2012-09-28 Thread Travis Leithead
note in Chome, that's due to the subtle difference in implementation of WebIDL per the above requirement. From: Rick Waldron [mailto:waldron.r...@gmail.com] Sent: Friday, September 28, 2012 4:24 PM To: Cameron McCormack Cc: Travis Leithead; Boris Zbarsky; public-script-co...@w3.org; pub

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

2012-09-28 Thread Rick Waldron
On Fri, Sep 28, 2012 at 4:14 PM, Cameron McCormack 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, rathe

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

2012-09-28 Thread Cameron McCormack
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.

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

2012-09-28 Thread Travis Leithead
> From: Boris Zbarsky [mailto:bzbar...@mit.edu] > > On 9/28/12 12:38 PM, Travis Leithead wrote: > > It seems more important to check for the features of the spec, rather > than spec support in general. I would expect if (URL.createObjectURL) for > example. > > You have it backwards. That's check

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

2012-09-28 Thread Boris Zbarsky
On 9/28/12 12:38 PM, Travis Leithead wrote: It seems more important to check for the features of the spec, rather than spec support in general. I would expect if (URL.createObjectURL) for example. You have it backwards. That's checking for the file API bits. How do you check whether you can

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

2012-09-28 Thread Travis Leithead
> From: Boris Zbarsky [mailto:bzbar...@mit.edu] > > On 9/28/12 4:28 AM, Cameron McCormack wrote: > > 1. Should we make it so that if you implement one or more partial > > interfaces but not the actual one, then an empty actual interface is > > implied? > > That's fine by me. > > > 2. Is it reall

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

2012-09-28 Thread Boris Zbarsky
On 9/28/12 4:28 AM, Cameron McCormack wrote: 1. Should we make it so that if you implement one or more partial interfaces but not the actual one, then an empty actual interface is implied? That's fine by me. 2. Is it really important to avoid a prototype from existing on URL in this case? I

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

2012-09-28 Thread Cameron McCormack
Boris Zbarsky: Should WebIDL change here? Should FileAPI change? Technically, it is not possible to implement File API without also implementing the URL specification, since if there is a "partial interface URL" then there must also be a "interface URL" in the set of IDL fragments that you

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

2012-09-24 Thread Travis Leithead
> From: Boris Zbarsky [mailto:bzbar...@mit.edu] > > On 9/21/12 12:39 PM, Travis Leithead wrote: > > I believe that firstly, the File API spec needs to be rationalized > against the URL API > > They're already there. File API explicitly says that if you support URL > API then you get a normal int

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

2012-09-21 Thread Boris Zbarsky
On 9/21/12 12:39 PM, Travis Leithead wrote: I believe that firstly, the File API spec needs to be rationalized against the URL API They're already there. File API explicitly says that if you support URL API then you get a normal interface object and proto object. Once that happens, I wond

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

2012-09-21 Thread Travis Leithead
> From: Boris Zbarsky [mailto:bzbar...@mit.edu] > > The spec currently says[1]: > >The value of the "prototype" property of an interface object for a >non-callback interface MUST be an object called the interface >prototype object. > > At the same time, we have specs like File API de

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

2012-09-21 Thread Boris Zbarsky
The spec currently says[1]: The value of the “prototype” property of an interface object for a non-callback interface MUST be an object called the interface prototype object. At the same time, we have specs like File API defining things like this: partial interface URL { } E