Re: in webIDL can a required dictionary member be nullable?

On Jul 18, 2015 11:07, "=JeffH" <Jeff.Hodges@kingsmountain.com> wrote:
>
> TJ replied..
>
> > On Thu, Jul 16, 2015 at 4:49 PM, =JeffH <Jeff.Hodges@kingsmountain.com>
wrote:
> >> Hi folks, I have a quick hopefully easy question I just need to
> >> double-check on..
> >>
> >> in webIDL 2nd Ed. [1] can a required dictionary member be nullable?
> >>
> >> e.g.  can one do this..
> >>
> >>   dictionary foo {
> >>     required DOMString? bar;
> >>     required DOMString? baz;
> >>   };
> >>
> >> ..?
> >>
> >> From my reading of [1], especially at [2], the answer is "yes" for the
> >> case of such a dictionary, correct?
> >
> > Absolutely. null is a value.
>
>
> Ok, thanks much, now another question..
>
> if we declare this non-nullable variant in a spec..
>
>    dictionary foo-EmptyStringOK {
>      required DOMString bar;
>      required DOMString baz;
>    };
>
> ..where the above is intended to describe a JSON-serialized on-the-wire
message, is it legitimate to have actual message instances where the value
of bar or baz are empty strings, eg "" ?   e.g.,
>
>   {"bar":"","baz":""}
>
> ..?

Yes, empty string is a string.

> my understanding is that a serialization of {"bar":null,"baz":null} would
NOT be ok in the case of foo-EmptyStringOK, but would be ok in the case of
the foo dictionary way up above because the DOMString members therein are
declared as nullable.

It would *never* be okay to serialize as null. Empty string is a string,
not a null. You can't switch types like that.

~TJ