Re: [NoInterfaceObject]

On Aug 29, 2011, at 22:26 , Andreas Gal wrote:
> The current draft of the W3C Contacts API annotates every interface with [NoInterfaceObject].
> 
> http://dev.w3.org/2009/dap/contacts/
> 
> I tried to discuss this with the working group, but they feel that its important to not pollute the global name space.

You make it sound like the group just rejected your suggestion. As stated in http://lists.w3.org/Archives/Public/public-device-apis/2011Aug/0061.html:

"The idea behind using NoInterfaceObject is to avoid global namespace pollution unless there happens to be a good use case for exposing a given object (which there may well be, it might simply not have been suggested yet)."

I'm willing to be convinced otherwise, but this doesn't strike me as an absolutely terrible idea. In general though, I agree that it would be valuable to groups (and editors in general) to have guidance as to the tradeoffs involved in a given construct. In my experience, editors tend to just paste another API and start modifying it. They also tend not to have read the WebIDL specification (skimmed yes, read no). This tells me that some form of primer (possibly very short, not aimed at total beginners) might be called for.

> I think this is wrong and breaks established DOM bindings patterns

I wouldn't assume that doing things differently from the DOM is necessarily bad. We don't have to care about Java.

> In some of the use cases in the W3C Contacts API dictionaries can be used (the working group is already receptive to this idea).

So receptive in fact that we even proposed it ;)

> For general APIs we should disallow [NoInterfaceObject].

Disallowing seems harsh — that's why I prefer your previous suggestion of explaining in which cases to use it.

> The Contacts API for example defines this:
> 
> [NoInterfaceObject]
> interface ContactError {
> const unsigned short UNKNOWN_ERROR = 0;
> ...
> }
> This seems really counter-intuitive. Developers will want to use this by name (ContactError.UNKNOWN_ERROR).

Actually we should just replace this with a string, using numerical constants for error names is daft. But otherwise your point holds.

> Instead of arguing with each working group about their particular view of what good DOM bindings look like, we should add some guidance in WebIDL.

Discussing it with every group that does APIs would certainly require more patience and commitment than can be asked of anyone. I agree with the guidance idea (are you volunteering to draft something? :) but as state above I'm unsure that the WebIDL spec itself is the best place for this.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 29 August 2011 20:49:55 UTC