Good use cases for WebIDL overloads?

In the recent thread with subject "Possible compat problem with
treating undefined as not passed in WebIDL", Boris brings up that the
current XHR.open() API is currently defined in a backwards compatible
way.

The problem is that the very old XHR.open() function has an optional
"async" argument that defaults to true if not passed. However in all
existing browsers explicitly passing 'undefined' is treated as
explicitly passing 'false'. That means that the current WebIDL
signature of

open(..., optional boolean async = true, ...)

is not backwards compatible since passing 'undefined' is equal to not
passing a value at all.

Obviously there's lots of badness here. Having optional arguments that
default to 'true' is asking for trouble. And the legacy behavior of
converting 'undefined' to false rather than treating it as not passed
is also bad. But we're about a decade too late to fix that.

This can be worked around in the spec by using WebIDL overloads.

This is arguably a bad thing. I.e. it makes it very easy to create
poor APIs just like the one the XHR uses. Likewise Canvas2D's
drawImage function is usually brought up both as an example of where
we need overloads, and as an example of a poorly designed API.

With the flexibility of optional arguments, default values, unions and
dictionaries, are there really good use cases for overloads other than
legacy APIs?

/ Jonas

Received on Friday, 4 October 2013 06:12:14 UTC