Re: nullable

On 8/26/14 9:17 AM, Michael Tuexen wrote:
> in
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcpeerconnection-interface-extensions
> the label argument of createDataChannel() is described as
> [TreatNullAs=EmptyString] DOMString label
> I read this that createDataChannel(NULL) is the same as createDataChannel("").
> Is that correct?

Yes.Remove [TreatNullAs=EmptyString] and it would be the same as 
createDataChannel("null"). [1]

> On the other hand, in the table shown in
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#methods-1
> it is stated that the label argument is not Nullable. What does this mean?

WebIDL compilers provide invariants to implementations through generated 
binding-code, and nullable means the implementation will see and must 
handle NULL as a discrete value (NULL != "", NULL != 0). Non-nullable 
means it wont. Nullable is a type-modifier, as a slightly more elaborate 
type is needed to hold NULL as a distinct value.

> Isn't that contradicting the above statement?

No,the binding-code for DOMString label converts NULL into "null" on 
input, so the implementation never sees or has to deal with 
NULL.[TreatNullAs=EmptyString] just replaces "null" with "".

Anullable string would be specified like this: DOMString? label

> Regarding send() it is stated in
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#methods-2
> that the data argument is shown as not Nullable. Does this mean that calling
> send(NULL) will result in an error/exception?

While most other types would throw TypeError at you, it seems DOMString 
always convertsNULL and undefined into a string [2] - likely a gift from 
javascript.

>   Does this need to be stated?

A benefit of using standard webidl is that we don't need to.

> Best regards
> Michael

.: Jan-Ivar :.

[1] http://www.w3.org/TR/WebIDL/#TreatNullAs
[2] http://www.w3.org/TR/WebIDL/#es-DOMString

Received on Wednesday, 27 August 2014 03:00:48 UTC