Re: Overload of Dictionary and Callback - why is this disallowed?

On 12/01/2015 05:05 PM, Domenic Denicola wrote:
> From: Boris Zbarsky [mailto:bzbarsky@mit.edu]
>
>> That said, I think we could, in fact, make callback functions and dictionaries
>> distinguishable.  It wouldn't even require any changes to the overload
>> resolution algorithm, as far as I can tell:
> I think we could, but it would be confusing to allow APIs to be designed that way, and should be discouraged.




>
>> That said, what is the actual use case here?  If this is a new API, you should
>> probably just use a dictionary and not create the two overloads.
> ... and if it's an old API, you should use prose.

Unfortunately it's one of the "used to be this way, but that turned out
to be a bad way, so we want another way" cases. In particular, we used
to have

function(callback, callback, optional dictionary)

but now we all agree that we should have

promise = function(optional dictionary)

There was an implementation (unfortunately heavily used) that did

function(callback, optional callback, optional dictionary)

which means that we can get calls to "function(x)" where x is either a
dictionary or a callback - but WebIDL doesn't allow us to distinguish
these cases through generated code.

Getting around this "in prose" requires hacks. And since our
implementation uses an IDL compiler, this requires our IDL to be
different from the spec's IDL in gratuitous ways.

We'd prefer to avoid adding hacks into the codebase if we can get this
done cleanly. If the IDL compiler were to dispatch the calls on the
basis of calling IsCallable() on the argument, that would seem to solve
our use cases.

(We're also following the path of counting the number of calls of
function(callback) and issuing deprecation warnings asking people to do
function(callback, callback) instead. But it will take time just to get
that information.)







-- 
Surveillance is pervasive. Go Dark.

Received on Tuesday, 1 December 2015 20:40:54 UTC