Re: Web IDL syntax
Cameron McCormack: I’ll think about it. :-) HTMLAppletElement can always have readonly attribute DOMString _object; to avoid conflicting with the reserved word. Ian Hickson: It's many years too late for that. The underscore is just an escaping mechanism. The identifier is still just object in this case. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL syntax
On Sat, 8 Aug 2009, Cameron McCormack wrote: Cameron McCormack: I’ll think about it. :-) HTMLAppletElement can always have readonly attribute DOMString _object; to avoid conflicting with the reserved word. Ian Hickson: It's many years too late for that. The underscore is just an escaping mechanism. The identifier is still just object in this case. Oh. Fancy. Ok, done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Web IDL syntax
On Aug 7, 2009, at 6:23 PM, Cameron McCormack wrote: Cameron McCormack: I’ll think about it. :-) HTMLAppletElement can always have readonly attribute DOMString _object; to avoid conflicting with the reserved word. Ian Hickson: It's many years too late for that. The underscore is just an escaping mechanism. The identifier is still just object in this case. Wouldn't that get in the way of the possibility of underscores in identifiers in the future? I think it would be simpler to just capitalize the Object keyword. - Maciej
Re: Web IDL syntax
Maciej Stachowiak: Wouldn't that get in the way of the possibility of underscores in identifiers in the future? The underscore-escaping is a feature from OMG IDL. I don’t know if it’s worth changing to a different character like a backslash. If you want an identifier to actually begin with an underscore, you use two. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL syntax
On Thu, 16 Jul 2009 12:16:00 +0200, Simon Pieters sim...@opera.com wrote: On Tue, 30 Jun 2009 09:07:22 +0200, Cameron McCormack c...@mcc.id.au wrote: 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 Having it optional will likely lead to inconsistently written IDLs, which can be confusing. I think it would be better to either require it (as legacy cruft, basically) or remove it altogether (the relevant IDLs will need to be rewritten anyway for the other changes). +1 to removing cruft. (Also, I'd hate to add it back to CSSOM View at this point :-P) -- Anne van Kesteren http://annevankesteren.nl/
Re: Web IDL syntax
I think the “Object”, “TRUE” and “FALSE” keywords should be made lowercase. It seems the lower case object has been used as an interface member in HTMLAppletElement. Probably should we keep Object as it is? Both true and false look fine with me. - Shiki
Re: Web IDL syntax
Shiki Okasaka: I think the “Object”, “TRUE” and “FALSE” keywords should be made lowercase. It seems the lower case object has been used as an interface member in HTMLAppletElement. Probably should we keep Object as it is? Both true and false look fine with me. I’ll think about it. :-) HTMLAppletElement can always have readonly attribute DOMString _object; to avoid conflicting with the reserved word. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL syntax
On Tue, 30 Jun 2009 09:07:22 +0200, Cameron McCormack c...@mcc.id.au wrote: 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 Having it optional will likely lead to inconsistently written IDLs, which can be confusing. I think it would be better to either require it (as legacy cruft, basically) or remove it altogether (the relevant IDLs will need to be rewritten anyway for the other changes). -- Simon Pieters Opera Software
Re: Web IDL syntax
Hi,
Any other vestiages from the past in the IDL that seems ripe for change?
'InterfaceInheritance' is currently defined as a ScopedNameList or
epsilon. But in practice I don't see any web interface that actually
uses the multiple interface inheritance like,
interface X : A, B, C
{
}
Is it possible to inhibit the multiple interface inheritance at the
Web IDL grammar level? Now that we have ImplementedOn or 'implements',
the multiple interface inheritance seems to be unnecessary to me.
Best,
- Shiki
On Fri, Jun 19, 2009 at 1:54 PM, Cameron McCormackc...@mcc.id.au wrote:
Hello WG.
I’m thinking about removing some of the extended attributes in Web IDL
and replacing them with non-extension syntax in the language.
Originally, I had a goal of keeping compatibility with OMG IDL, which is
why many features currently require extended attributes. Upon
reflection, I don’t think compatibility with OMG IDL syntax is a useful
goal, especially when it gets in the way of neatly specifying particular
requirements.
So if we are happy to extend the IDL syntax, I think any extended
attribute that is intended to have some effect across all language
bindings should be moved to the syntax proper. Following are my half
baked proposals. I haven’t them through much; comments very much
welcome.
Thanks,
Cameron
Changes to extended attributes
--
[Callable]
Callable objects would be specified using an operation-like syntax.
interface NumberQuadrupler {
callable float compute(in float x);
};
Would mean that in languages where objects can be callable,
NumberQuadruplers would be callable, but wouldn’t have a method called
“compute”. Languages that do not support callable objects would have
the “compute” method.
You would also be able to specify a separate callable:
interface NumberQuadrupler {
callable float (in float x);
};
where for langauges that don’t support callable objects, there wouldn’t
be any method on NumberQuadrupler objects.
[Constructor]
I’d say to keep this as an extended attribute, but make it be
ECMAScript-specific. If factory methods are required across language
bindings, then explicit factory interfaces should be written.
[ExceptionConsts]
This should be dropped, and instead the IDL syntax would allow constants
to be specified on exceptions directly.
module fileio {
exception FileIOException {
const unsigned short FILE_NOT_FOUND = 1;
const unsigned short READ_ERROR = 2;
const unsigned short WRITE_ERROR = 3;
unsigned short code;
};
};
[ImplementedOn]
I’d like to take up Ian’s suggestion
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0362.html
of syntax to specify when objects implementing interface A always
implement interface B.
Instead of having:
[ImplementedOn=Node]
interface EventTarget {
…
};
you would have:
interface EventTarget {
…
};
Node implements EventTarget;
and for the reverse case, where Anne requested an [Implements] extended
attribute
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0360.html
you would have:
interface XMLHttpRequestUpload {
…
};
XMLHttpRequestUpload implements EventTarget;
Note that using interface inheritance is slightly different from this
“implements” syntax, since the former makes particular requirements of
the prototype chain in ECMAScript and the actual inheritance hierarchy
in Java.
[{Index,Name}{Creator,Deleter,Getter,Setter}]
As with the “callable” keyword, indexing operations would be specified
with operation-like syntax.
interface OrderedMap {
readonly attribute unsigned size;
getter any getByIndex(in unsigned long index);
setter void setByIndex(in unsigned long index, in any value);
deleter void removeByIndex(in unsigned long index);
getter any get(in DOMString name);
creator setter void set(in DOMString name, in any value);
deleter void remove(in DOMString name);
};
As with “callable”, the “getter”, “creator”, “setter” and “deleter”
modifiers on an operation indicate that if the language binding supports
object indexing like this, the methods won’t exist. To have a getter
that exists in ECMAScript while also keeping the method, you’d do:
interface HTMLCollection {
…
Element item(in unsigned long index);
getter Element (in unsigned long index);
…
};
An alternative would be to reverse the omission of methods, so that
“getter” on an operation would always have both the getter. Then if you
wanted to omit the method if getters are supported you could do
something like:
interface DOMStringMap {
omittable getter DOMString get(in DOMString name);
omittable setter void set(in DOMString name, in DOMString value);
…
};
and getters/setters defined with no operation name would be implicitly
omittable.
Not sure which of the above two ways is better, at the
Re: Web IDL syntax
Shiki Okasaka:
'InterfaceInheritance' is currently defined as a ScopedNameList or
epsilon. But in practice I don't see any web interface that actually
uses the multiple interface inheritance like,
interface X : A, B, C
{
}
SVG does:
http://dev.w3.org/SVG/profiles/1.1F2/publish/idl.html
Admittedly this isn’t Web IDL, still OMG IDL.
Is it possible to inhibit the multiple interface inheritance at the
Web IDL grammar level? Now that we have ImplementedOn or 'implements',
the multiple interface inheritance seems to be unnecessary to me.
There is a subtle difference between ‘implements’ and multiple
inheritance. In Java, ‘interface X : A, B, C’ will result in a Java
interface that looks like
public interface X extends A, B, C {
}
while having
interface X { };
X implements A;
X implements B;
X implements C;
will just correspond to
public interface X {
}
and all X objects will happen to implement A, B and C.
In ECMAScript there is no difference.
Also note that I’ve dropped [ImplementedOn] in favour of the
‘implements’ statement, although I notice just now that there are still
a couple of references to it that I need to remove.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL syntax
SVG does:
http://dev.w3.org/SVG/profiles/1.1F2/publish/idl.html
Admittedly this isn’t Web IDL, still OMG IDL.
I see. Thanks Cameron. So even though it seems those can be replaced
by 'implements', is it not a plan?
- Shiki
On Fri, Jul 10, 2009 at 12:23 PM, Cameron McCormackc...@mcc.id.au wrote:
Shiki Okasaka:
'InterfaceInheritance' is currently defined as a ScopedNameList or
epsilon. But in practice I don't see any web interface that actually
uses the multiple interface inheritance like,
interface X : A, B, C
{
}
SVG does:
http://dev.w3.org/SVG/profiles/1.1F2/publish/idl.html
Admittedly this isn’t Web IDL, still OMG IDL.
Is it possible to inhibit the multiple interface inheritance at the
Web IDL grammar level? Now that we have ImplementedOn or 'implements',
the multiple interface inheritance seems to be unnecessary to me.
There is a subtle difference between ‘implements’ and multiple
inheritance. In Java, ‘interface X : A, B, C’ will result in a Java
interface that looks like
public interface X extends A, B, C {
}
while having
interface X { };
X implements A;
X implements B;
X implements C;
will just correspond to
public interface X {
}
and all X objects will happen to implement A, B and C.
In ECMAScript there is no difference.
Also note that I’ve dropped [ImplementedOn] in favour of the
‘implements’ statement, although I notice just now that there are still
a couple of references to it that I need to remove.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL syntax
Shiki Okasaka: I see. Thanks Cameron. So even though it seems those can be replaced by 'implements', is it not a plan? They could be replaced with ‘implements’, but not without breaking Java bindings. Existing code that compiles against the SVG 1.1 interfaces might not compile against them if converted to use ‘implements’. So it’s not my plan to remove multiple inheritance at the moment, no. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL syntax
Cameron McCormack: I can easily rename the type back to DOMString . I’d like to know if you all think there is any problem in keeping the name as DOMString but removing the null from its set of values, and requiring the use of the nullable type ‘DOMString?’ to specify a string type that does allow null. Because then it is different from the traditional DOMString as defined in DOM Core. Maciej Stachowiak: I haven't investigated this deeply. I'm not sure it is meaningful in ECMAScript to say that null is not allowed in some particular case - rather, it is necessary to specify what happens when null is passed. I agree that we need to specify what happens when null is passed, just as we need to specify what happens when any kind of ECMAScript value is passed. That doesn’t make it not useful to specify in the IDL what values are expected. To me, it seems like some operations have useful behaviour defined for strings and some for strings plus the value null. If the null value is not useful across all language bindings, then I think that should be part of the actual argument type, rather than an annotation. There's extended attributes to specify that it should be treated as , undefined, or null, so it seems odd to have a different type to say it should be treated as the string null. I'm not sure if I correctly interpreted what you meant by allow null. It wouldn’t be that you have a different type just to mean “treat it as the string null”. It would be that this type (‘DOMString’, as opposed to ‘DOMString?’) has behaviour which is not to just pass the null value through untouched. By “allow null” I mean whether the operation/attribute on the IDL level is expecting null as a valid value. So, with the changes I’ve made, the valid values of the DOMString type are all possible strings (i.e., sequences of 16 bit code units), and the valid values of the DOMString? type are all possible strings PLUS the null the value. Operations and attributes of type ‘DOMString?’ would always pass a null value through unconverted (well, except for the conceptual conversion from the ECMAScript null value to the IDL null value). Operations and arguments of type ‘DOMString’ would always convert a null value into some kind of string value. The default for this is still to convert it to the string null, which can be changed to by using [TreatNullAs=EmptyString]. But I’m open to switching this around, I just still haven’t got around to testing exhaustively to see which would is more common. Does this make sense? Also, as I understand it, there's no way in the Java type system to exclude null from the range of a reference type, so there too it's necessary to say what happens with a null string (exception, same as empty, special behavior different from any string). Right, just as there’s no way to do it in ECMAScript because there is no strong typing. Currently the spec says to throw a NullPointerException if null is passed to something of type DOMString in Java. For ‘DOMString?’, it is passed through unchanged. If special behaviour different from any string is needed, then the operation/attribute really should have been defined to take a ‘DOMString?’, i.e. a type that includes the null value. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL syntax
Cameron McCormack: I can easily rename the type back to DOMString. I’ve renamed it back, but still left null out of its set of values. -- Cameron McCormack ≝ http://mcc.id.au/
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 ':',
Re: Web IDL syntax
Cameron McCormack wrote: * Renamed DOMString to string: http://dev.w3.org/2006/webapi/WebIDL/#idl-string I thought there had been at least some mention of this colliding with existing string types in IDLs that are already in use? I know this will make it much harder for Mozilla to use webidl IDL fragments as is... -Boris
Re: Web IDL syntax
Boris Zbarsky: Are we going to rewrite the existing DOM spec idl to the new syntax as needed (e.g getElementsByTagNameNS)? I do think somebody needs to do that. I don’t think it’s sufficient (even before this syntax change) to just rely on interepreting the OMG IDL published in DOM Core as Web IDL. At the least, [PrototypeRoot] needs to be specified on the Node interface, so that ECMAScript prototype chains for, say, HTMLAElement are set up appropriately. I know that Simon Pieters is working on Web DOM Core http://simon.html5.org/specs/web-dom-core but I am not sure when that will be done. It also won’t include everything from DOM 3 Core. I think it might be useful for someone to just publish versions of existing DOM specs’ IDL as Web IDL. I’m willing to help with that. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL syntax
On Jun 30, 2009, at 7:05 PM, Cameron McCormack wrote: Maciej Stachowiak: WebKit doesn't have the same technical constraints as Mozilla, however this change doesn't really seem helpful and it would be annoying to have to replace all instances of DOMString in our existing IDL. find . -name \*.idl | xargs perl -i -pe s/\DOMString\/string/g But OK. By the way, do you use DOMString as an intrinsic type, or do you use a sequenceunsigned long boxed valuetype (as defined in DOM Core)? We treat it as an intrinsic type. I can easily rename the type back to DOMString. I’d like to know if you all think there is any problem in keeping the name as DOMString but removing the null from its set of values, and requiring the use of the nullable type ‘DOMString?’ to specify a string type that does allow null. Because then it is different from the traditional DOMString as defined in DOM Core. I haven't investigated this deeply. I'm not sure it is meaningful in ECMAScript to say that null is not allowed in some particular case - rather, it is necessary to specify what happens when null is passed. There's extended attributes to specify that it should be treated as , undefined, or null, so it seems odd to have a different type to say it should be treated as the string null. I'm not sure if I correctly interpreted what you meant by allow null. Also, as I understand it, there's no way in the Java type system to exclude null from the range of a reference type, so there too it's necessary to say what happens with a null string (exception, same as empty, special behavior different from any string). Regards, Maciej
Re: Web IDL syntax
On Jun 23, 2009, at 05:41 , Shiki Okasaka wrote: 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. 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. I like that option, the ability to not use in would be really nice to have. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Web IDL syntax
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.
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.
- Shiki
On Fri, Jun 19, 2009 at 3:09 PM, Ian Hicksoni...@hixie.ch wrote:
On Fri, 19 Jun 2009, Cameron McCormack wrote:
An alternative would be to reverse the omission of methods, so that
“getter” on an operation would always have both the getter. Then if
you wanted to omit the method if getters are supported you could do
something like:
interface DOMStringMap {
omittable getter DOMString get(in DOMString name);
omittable setter void set(in DOMString name, in DOMString value);
…
};
and getters/setters defined with no operation name would be implicitly
omittable.
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.
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.
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.
--
Ian Hickson U+1047E )\._.,--,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Web IDL syntax
On Fri, 19 Jun 2009, Cameron McCormack wrote:
An alternative would be to reverse the omission of methods, so that
“getter” on an operation would always have both the getter. Then if
you wanted to omit the method if getters are supported you could do
something like:
interface DOMStringMap {
omittable getter DOMString get(in DOMString name);
omittable setter void set(in DOMString name, in DOMString value);
…
};
and getters/setters defined with no operation name would be implicitly
omittable.
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.
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.
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.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Web IDL syntax
On Fri, 19 Jun 2009 06:54:45 +0200, Cameron McCormack c...@mcc.id.au wrote: So if we are happy to extend the IDL syntax, I think any extended attribute that is intended to have some effect across all language bindings should be moved to the syntax proper. Following are my half baked proposals. I haven’t them through much; comments very much welcome. In general this seems fine to me. As long as you help reviewing specifications that use Web IDL :-) -- Anne van Kesteren http://annevankesteren.nl/
RE: Web IDL syntax
Hi Cameron, I will review your proposal in detail soon. In general this seems fine to me. As long as you help reviewing specifications that use Web IDL :-) +1 Please bear in mind that there are specs that rely on Web IDL. E.g. BONDI (http://bondi.omtp.org/1.0/) defines in Web IDL: 178 methods, 82 constants and 116 attributes over 68 interfaces as summarized here: http://bondi01.obe.access-company.com/1_0_3309_41/stats.html so stability of the Web IDL spec MAY be important. Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Anne van Kesteren Sent: Friday, June 19, 2009 10:51 AM To: Cameron McCormack; public-webapps@w3.org Subject: Re: Web IDL syntax On Fri, 19 Jun 2009 06:54:45 +0200, Cameron McCormack c...@mcc.id.au wrote: So if we are happy to extend the IDL syntax, I think any extended attribute that is intended to have some effect across all language bindings should be moved to the syntax proper. Following are my half baked proposals. I haven’t them through much; comments very much welcome. In general this seems fine to me. As long as you help reviewing specifications that use Web IDL :-) -- Anne van Kesteren http://annevankesteren.nl/ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: Web IDL syntax
Hi Cameron, On Jun 19, 2009, at 06:54 , Cameron McCormack wrote: I’m thinking about removing some of the extended attributes in Web IDL and replacing them with non-extension syntax in the language. Originally, I had a goal of keeping compatibility with OMG IDL, which is why many features currently require extended attributes. Not only do I think that compatibility with OMG IDL isn't useful, I also don't think that WebIDL is currently compatible — or at the very that as written it enforces the creation WebIDL documents that are also well-formed OMG IDLs. One example is case-sensitivity: OMG IDL is case-preserving but compares identifiers in a case-insensitive manner (and I forget the scope of the comparison, but I think it's per *module*); that's one of the reasons why some of the SVG IDLs originally claimed conformance to nothing. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Web IDL syntax
Hello WG.
I’m thinking about removing some of the extended attributes in Web IDL
and replacing them with non-extension syntax in the language.
Originally, I had a goal of keeping compatibility with OMG IDL, which is
why many features currently require extended attributes. Upon
reflection, I don’t think compatibility with OMG IDL syntax is a useful
goal, especially when it gets in the way of neatly specifying particular
requirements.
So if we are happy to extend the IDL syntax, I think any extended
attribute that is intended to have some effect across all language
bindings should be moved to the syntax proper. Following are my half
baked proposals. I haven’t them through much; comments very much
welcome.
Thanks,
Cameron
Changes to extended attributes
--
[Callable]
Callable objects would be specified using an operation-like syntax.
interface NumberQuadrupler {
callable float compute(in float x);
};
Would mean that in languages where objects can be callable,
NumberQuadruplers would be callable, but wouldn’t have a method called
“compute”. Languages that do not support callable objects would have
the “compute” method.
You would also be able to specify a separate callable:
interface NumberQuadrupler {
callable float (in float x);
};
where for langauges that don’t support callable objects, there wouldn’t
be any method on NumberQuadrupler objects.
[Constructor]
I’d say to keep this as an extended attribute, but make it be
ECMAScript-specific. If factory methods are required across language
bindings, then explicit factory interfaces should be written.
[ExceptionConsts]
This should be dropped, and instead the IDL syntax would allow constants
to be specified on exceptions directly.
module fileio {
exception FileIOException {
const unsigned short FILE_NOT_FOUND = 1;
const unsigned short READ_ERROR = 2;
const unsigned short WRITE_ERROR = 3;
unsigned short code;
};
};
[ImplementedOn]
I’d like to take up Ian’s suggestion
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0362.html
of syntax to specify when objects implementing interface A always
implement interface B.
Instead of having:
[ImplementedOn=Node]
interface EventTarget {
…
};
you would have:
interface EventTarget {
…
};
Node implements EventTarget;
and for the reverse case, where Anne requested an [Implements] extended
attribute
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0360.html
you would have:
interface XMLHttpRequestUpload {
…
};
XMLHttpRequestUpload implements EventTarget;
Note that using interface inheritance is slightly different from this
“implements” syntax, since the former makes particular requirements of
the prototype chain in ECMAScript and the actual inheritance hierarchy
in Java.
[{Index,Name}{Creator,Deleter,Getter,Setter}]
As with the “callable” keyword, indexing operations would be specified
with operation-like syntax.
interface OrderedMap {
readonly attribute unsigned size;
getter any getByIndex(in unsigned long index);
setter void setByIndex(in unsigned long index, in any value);
deleter void removeByIndex(in unsigned long index);
getter any get(in DOMString name);
creator setter void set(in DOMString name, in any value);
deleter void remove(in DOMString name);
};
As with “callable”, the “getter”, “creator”, “setter” and “deleter”
modifiers on an operation indicate that if the language binding supports
object indexing like this, the methods won’t exist. To have a getter
that exists in ECMAScript while also keeping the method, you’d do:
interface HTMLCollection {
…
Element item(in unsigned long index);
getter Element (in unsigned long index);
…
};
An alternative would be to reverse the omission of methods, so that
“getter” on an operation would always have both the getter. Then if you
wanted to omit the method if getters are supported you could do
something like:
interface DOMStringMap {
omittable getter DOMString get(in DOMString name);
omittable setter void set(in DOMString name, in DOMString value);
…
};
and getters/setters defined with no operation name would be implicitly
omittable.
Not sure which of the above two ways is better, at the moment.
[NoIndexingOperations]
This wouldn’t be needed, since the above changes to specifying getters
and setter would allow you to specify whether the methods get included
or not.
[Null]
This would become an ECMAScript-specific extended attribute.
[Optional]
Optional arguments would be able to be specified using an “optional”
keyword, like so:
interface ColorCreator {
Object createColor(in float v1,
in optional float v2,
in float v3,
in optional flat alpha);
};
“optional” would still mean “this and all following arguments can be
omitted”.
[Prefix]
This was
Re: Web IDL syntax
Cameron McCormack: Other possible syntax changes - And another one: get rid of the requirement to use forward declarations if you want mutually referencing interfaces. -- Cameron McCormack ≝ http://mcc.id.au/
