On May 20, 2007, at 7:31 PM, Cameron McCormack wrote:
Cameron McCormack:
I’m starting to write some text for Bindings4DOM, and am wondering
which
direction to take for method overloading.
Ian suggests (in IRC) that we go for the “W3C IDL” option so that more
ECMAScript specific functionality can go directly into the IDL. Then
things like whether an attribute is DontEnum or whatever could be
specified like so:
interface NodeList {
// in Opera you can delete NodeList.prototype.item;
Node item(in unsigned long index);
// but you can’t delete NodeList.prototype.length;
readonly DontDelete attribute unsigned long length;
I think DOM attributes are generally DontDelete, so it would make more
sense to note the exceptions that are deletable.
// define the array indexing behaviour
Node [[Get]](in unsigned long index);
// and maybe you need to give the behaviour for real property
// lookups (or maybe it would default to having this behaviour)
any [[Get]](in any propName);
I think special access by index and name should be specified on the
interface, not as specially named methods, like
interface NodeList[IndexAccess=Item] {
}
BTW I think brackets are free for use by IDL extensions so we could
use them for any extensions and still sort of be OMG IDL compatible.
}
There are two targets of the bindings spec in my mind: one is spec
writers, who want to be able to refer to the bindings spec and have
useful definitions to make their job easier when writing specs that
will
be used with ECMAScript; the other is implementors, who may use the
IDL
for code generation.
Going with “W3C IDL” certainly helps the spec writers, since it means
they can stick ES-specific things more succinctly in the IDL (at the
expense of being less language neutral). Would this extra information
in the IDL (rather than in some prose in the other spec, or in the
bindings spec that is then referenced by the other spec) help
implementors who use the IDL for code generation?
In WebKit, we use extended attributes heavily in our IDL for code
generation. Some are just implementation details, but others affect
the interface. Some exceptions from our Document.idl:
interface [GenerateConstructor] Document : EventTargetNode {
readonly attribute [ConvertNullStringTo=Null] DOMString
inputEncoding;
readonly attribute [ConvertNullStringTo=Undefined] DOMString
readyState;
[ConvertNullStringTo=False] DOMString queryCommandValue(in
DOMString command);
}
Notice that nominal null strings are in practice returned in at least
3 different ways to JS (null, undefined and false), yet still other
possibilities are returning the empty string or the string "null".
Sometimes there are quirks to the conversion *from* JS as well, on
input arguments or when assigning non-readonly attributes.
GenerateConstructor means there should be window.Document and
window.Document.prototype defined (although window.Document can't
actually be used as a constructor with "new" in JS, it is otherwise
similar to a global constructor object).
Things we don't have in our IDL yet are descriptions of which DOM
attributes should be replaceable (nominally readonly but can be
replaced with any value through a simple assignment, even ones of the
wrong type), shadowable (can be shadowed by a "var" declaration,
likely this applies only to Window properties) and shadowable by a
function delcaration. I plan to do research on which of these applies
for what Window property as part of the Window object spec. We also
generally treat overloading as optional arguments:
void scrollIntoView(in [Optional] boolean alignWithTop);
I don't think this is sufficient to describe window.open or
window.setTimeout though.
Regarrds,
Maciej
