W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2013

[Bug 23532] Dealing with undefined

From: <bugzilla@jessica.w3.org>
Date: Wed, 23 Oct 2013 06:33:25 +0000
To: public-script-coord@w3.org
Message-ID: <bug-23532-3890-69t37CtjAr@http.www.w3.org/Bugs/Public/>

--- Comment #12 from Boris Zbarsky <bzbarsky@mit.edu> ---
So I've thought about this some more.

This bug's proposal (comment 0) comes down to making a whole bunch of methods
that currently do not throw in certain cases start throwing in those cases.

Specifically, converting undefined to non-nullable interface arguments threw
anyway.  But conversion to nullable interface arguments used to produce null
and would now throw, and conversion to primitives used to produce
0/false/"undefined" (depending on the kind of primitive) and would now throw.

I strongly suspect that such a change is not web-compatible wholesale, which
means that if we make it we will need to explicitly flag various APIs that are
exceptions to the general rule for web compat purposes.  Coming up with such a
list of APIs would be at best time-consuming and error-prone (in the sense of
shipping browsers that break websites and finding out about that the hard way).

I do not expect Gecko to ship such a change before other UAs have done so and
have submitted feedback on which APIs they had to munge for compat reasons
(which is not a given, since other UAs seem to have a history of not submitting
such feedback at all).  I strongly doubt any other UA vendors are any more
willing than I am to stick their hands into this meat-grinder, but if they are
they should of course speak up!

Another, perhaps less breakage-prone, way to get to the world proposed in
comment 0 is to simply drop all arguments.length checks from WebIDL altogether
and just blindly coerce things as needed.  So omitting a Node argument would
still throw, but omitting a "Node?" argument would in fact act just like
passing explicit undefined would.  A bunch of stuff like calling setAttribute()
with only one argument (or no arguments, for that matter) which is currently
specified to throw would stop throwing, which is a safer change to make than
the reverse, albeit one that leads to less-debuggable code.  In this world, I'm
not quite sure how overload resolution will work, but if this is the direction
we want to go we can try to figure that out.  In some ways, overloaded methods
that cannot be reexpressed in terms of unions are already so whack that it
doesn't matter _that_ much how we resolve them.  :(

I should note that the "less breakage-prone" world is where WebKit and Blink
already live, as far as I can tell.  Try
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2580 in Chrome or

You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 23 October 2013 06:33:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC