Re: Web IDL syntax

Cameron McCormack:
> Following are my half baked proposals.

I’ve now baked all of these proposals into the spec, except for the one
about allowing multiple module levels with a module declaration (i.e.,
‘module a::b::c’).

  * Made ‘in’ optional
    http://dev.w3.org/2006/webapi/WebIDL/#idl-operations

  * Dropped [ImplementedOn] in favour of an ‘implements’ statement
    http://dev.w3.org/2006/webapi/WebIDL/#idl-implements-statements

  * Changed "Object", "TRUE" and "FALSE" to lowercase
    http://dev.w3.org/2006/webapi/WebIDL/#idl-grammar

  * Dropped [Optional] and [Variadic] in favour of ‘optional’ and ‘...’
    http://dev.w3.org/2006/webapi/WebIDL/#dfn-variadic-operation
    http://dev.w3.org/2006/webapi/WebIDL/#dfn-optional-argument

  * Dropped [ExceptionConsts] in favour of allowing constants to be
    defined directly on exceptions
    http://dev.w3.org/2006/webapi/WebIDL/#idl-exceptions

  * Replaced [Callable], [IndexGetter], [Stringifies], etc. with real
    IDL syntax
    http://dev.w3.org/2006/webapi/WebIDL/#idl-special-operations

  * Changed [NameGetter=OverrideBuiltins] into [OverrideBuiltins]
    http://dev.w3.org/2006/webapi/WebIDL/#OverrideBuiltins

  * Renamed DOMString to string:
    http://dev.w3.org/2006/webapi/WebIDL/#idl-string

If you’re writing a dependent spec and need help changing your IDL to
match the changes I’ve made, let me know.


Two (perhaps more controversial? or at least undiscussed) changes I’ve
made with this commit are to replace boxed valuetypes with the concept
of nullable types, like there are in C#, and to remove null from the set
of values string (née DOMString) can take.

  http://dev.w3.org/2006/webapi/WebIDL/#idl-nullable-type
  http://dev.w3.org/2006/webapi/WebIDL/#idl-string

A while ago, there was some discussion about whether null should indeed
be a member of that type.  Jonas made a comment at one point about it
being strange to have null be a valid DOMString value while having the
default conversion behaviour being that a JS null value was treated as
the string "null".  So now authors of IDL will need to make a conscious
decision about whether null is a valid value for attributes and
operation arguments that take strings.  The type ‘string’ doesn’t allow
null, while the type ‘string?’ does:

  interface X {
    attribute string a;
    [TreatNullAs=EmptyString] attribute string b;
    attribute string? c;
    [TreatUndefinedAs=EmptyString] attribute string d;
    [TreatUndefinedAs=Null] attribute string? e;
  };

  x.a = null;       // assigns "null"
  x.a = undefined;  // assigns "undefined"
  x.b = null;       // assigns ""
  x.c = null;       // assigns null
  x.c = undefined;  // assigns "undefined"
  x.d = undefined;  // assigns ""
  x.e = undefined;  // assigns null

(Oh yeah, I renamed [Null] and [Undefined] to [TreatNullAs] and
[TreatUndefinedAs] to give them more descriptive names.)

The issue of whether these are the right defaults is still open.  I
haven’t had time to finish detailed testing to see whether defaulting to
stringification is the best.

  http://dev.w3.org/2006/webapi/WebIDL/#TreatNullAs
  http://dev.w3.org/2006/webapi/WebIDL/#TreatUndefinedAs
  http://dev.w3.org/2006/webapi/WebIDL/#es-string
  http://dev.w3.org/2006/webapi/WebIDL/#es-nullable-type


Cameron McCormack:
> > An alternative would be to reverse the omission of methods, so that 
> > “getter” on an operation would always have both the getter.

Ian Hickson:
> I prefer "omittable" because it would mean I wouldn't have to say "and the 
> setter works like this other method" in prose all the time.

I’ve done it this way.

  http://dev.w3.org/2006/webapi/WebIDL/#idl-special-operations

> > If we are breaking syntax, then it seems more compelling to make 
> > “DOMString” be “string”.
> > 
> > Maybe we could drop the “in” keyword.  Seems better to stick with 
> > plain “in” arguments, for compatibility across language bindings, 
> > than to also allow “out” and “inout” ones.
> 
> I'd vote for not changing these, because we already have a lot of IDL out 
> there and it would be a pain to fix it all.

I tried changing DOMString to string and liked the look of it, so I’m
leaving it in for now.  There isn’t much Web IDL content out there yet,
so I think we’re still at a stage where it’s manageable to change.  If
you need help changing this (and the other syntax changes) in HTML 5,
let me know and I’ll supply a patch against
http://svn.whatwg.org/webapps/source.

> Regarding 'implements' (heycam and I talked about this on IRC recently; 
> I just wanted to get some notes down on the record):
> 
> There are three use cases that need covering:
> 
>  - inheritance (e.g. Node -> Element -> HTMLElement -> HTMLAnchorElement)
> 
>  - interfaces that are to be implemented by many other objects (e.g. 
>    EventTarget)
> 
>  - interfaces that are defined across multiple specs (e.g. Window, 
>    WorkerUtils, HTMLBodyElement's attributes and methods being separated 
>    from its deprecated attributes and methods)
> 
> The first is handled by ':', the second is handled by 'implements'. I 
> think we need the third also.

Haven’t got to this one yet.

Shiki Okasaka:
> Can we make "in" optional so that new interfaces can be defined
> without using "in"? It seems very easy to forget to specify "in" for
> each parameter in Web IDL.

OK, done.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Tuesday, 30 June 2009 07:08:09 UTC