Re: [Bindings] comments

Hi Anne.

Anne van Kesteren:
> I think we should rename this specification to "Web IDL" as it defines an  
> IDL language to be used by Web APIs. It also defines a mapping to language  
> bindings, but that aspect is less interesting.

Well, I think the IDL is only interesting when it can be mapped to
concrete languages.  I don’t feel terribly strongly about either the
current name or “Web IDL”.  Renaming has some non-zero overhead, though.
If others think it’s a more accurate name and is worth the effort of
renaming, I don’t mind.

> http://www.w3.org/TR/2007/WD-DOM-Bindings-20071017/#Overloads is really  
> inconvenient from a specification editor perspective. I would like the IDL  
> syntax to look a lot more like the IDL syntax in the XMLHttpRequest  
> specification. That the four "different" open() methods map to different  
> methods in languages that do not support overloading is ok, but ideally  
> the IDL stays simple. For my part the names for other languages are  
> auto-generated. open_1, open_2, etc. If that is really unacceptable I'd  
> like to know how much additional text is needed in the XMLHttpRequest  
> specification to cover for those three additional methods. If there's  
> indeed need for additional text besides rewriting that part of the IDL it  
> seems like this is not the optimal solution as in the end we want to write  
> less.

I’m not terribly happy with how it is at the moment either.  It would
make sense to optimise for the more common case of overloading being
available in the language, especially since the two specific language
bindings being defined in the document support overloading.

I’ll rework it to allow the same identifier to be used for different
operation names on the one interface, and add some language to say what
to do for a hypothetical language binding that doesn’t support
overloading.

> And send() / drawImage() type of overloading is necessary, but that seems  
> to be mentioned already, albeit with some open issues which I'm not sure  
> how to resolve. Maybe by giving languages that don't do it separate  
> methods?

For the drawImage() case, having separate methods seems sensible for
such languages.  For send(), it’s overkill, since you want send(null) to
behave the same way regardless of whether you call the Document version
or the DOMString version.  I’ll have to think about it some more.

> It would be really good if we had a way to say that a particular interface  
> is exposed on the global object in ECMAScript. For instance, it makes  
> sense to have window.XMLHttpRequest, but window.DocumentSelector is not  
> necessary given that you already have window.Document.

Would you settle for a way to say a particular interface isn’t exposed
on the global object? :)

One possible reason to expose DocumentSelector is so that you can
replace methods on the prototype, e.g.:

  DocumentSelector.prototype.enableStylesheetsForSet = …

which you can’t really do if you just have access to Document.

And also to be able to do:

  if (x instanceof DocumentSelector) …

Perhaps for this particular interface there isn’t much of a use case for
messing with the prototype, but is there much reason to prevent it?

Anyway, I’ve added a [NoInterfaceObject] extended attribute for this.

  http://lists.w3.org/Archives/Member/member-webapi-cvs/2008Jan/0002.html

> For constructors, I was wondering whether it's desirable to be able to  
> express the Image() constructor on HTMLImageElement or not. (If so, you'd  
> need a way to name a constructor.) The way HTML 5 solves that problem  
> currently seems pretty simple too. In addition constructors probably need  
> to be able to deal with overloading as well.

Maybe.  They are peculiarities, and there probably won’t be more of
these type of constructors-with-different-names.  Since they are only
useful for ECMAScript, and given the relatively simple definition of
them in HTML 5, I’m inclined not to add some more syntax to allow it.
I’ve put an ednote in the document mentioning it, though.

-- 
Cameron McCormack, http://mcc.id.au/
 xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au

Received on Tuesday, 1 January 2008 07:39:26 UTC