Null[C]String() has been renamed Void[C]String()

[Nicholas Nethercote]

Hi,

I just landed patches from bug 1401813 that rename Null[C]String() as
Void[C]String(). The commit message has the rationale:

> XPCOM's string API doesn't have the notion of a "null string". But it
does have
> the notion of a "void string" (or "voided string"), and that's what these
> functions are returning. So the names should reflect that.

This probably won't affect most people, because void strings are a niche
feature.

Nick

[Boris Zbarsky]

On 9/22/17 2:41 AM, Nicholas Nethercote wrote:
> This probably won't affect most people, because void strings are a niche
> feature.

Not in the DOM. They're used anytime you see "DOMString?" in webidl.
http://searchfox.org/mozilla-central/search?q=DOMString%3F&path=webidl
shows several hundred hits.

Looking at the diff from bug 1401813, it looks like some of the uses are
in fact using the XPCOM "void string" feature per se, while some are
conceptually trying to represent "JS null" (e.g. in nullable string
types about to be passed to JS) and for those having a concept of null
string, in the sense defined by dom/base/nsDOMString.h, makes sense.

Put another way, in the new setup the element lifecycle callbacks code
in Element::SetAttrAndNotify/UnsetAttr is much more confusing than it
used to be...

-Boris

[Eric Rahm]

The problem is these were never a null string, they're a voided empty
string. If you do a `str.get()` it gives you a valid pointer, not nullptr.
Regardless, while this was primarily a string change, we probably should
have pinged a dom peer; I had forgotten the weirdness that is DOMString
[1]. Arguably that API should be taking a maybe param and arguably we
should get rid of the void concept but that's not straightforward.

As a workaround for readability I think it would be reasonable to add some
sort of `using NullString = VoidString` to DOMString.h.

-e

[1]
http://searchfox.org/mozilla-central/rev/15ce5cb2db0c85abbabe39a962b0e697c9ef098f/dom/bindings/DOMString.h#153-173

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Boris Zbarsky]

On 9/22/17 1:31 PM, Eric Rahm wrote:
> The problem is these were never a null string, they're a voided empty
> string.

Sure. In the DOM usage, it's "a string that will convert to JS null
when converting to 'DOMString?'", and not anything about the string
itself being null.

> Arguably that API should be taking a maybe param and arguably we
> should get rid of the void concept but that's not straightforward.

Yes, on both counts.

There are some complications, as you note, if we want to avoid making
too many string copies, etc. In particular, making something like
"Nullable<nsAString>" (or equivalent with Maybe) work is a bit complicated.

> As a workaround for readability I think it would be reasonable to add some
> sort of `using NullString = VoidString` to DOMString.h.

That seems pretty reasonable for now.

-Boris