APIs that overload numbers and strings

Right now WebIDL cannot express an API that overloads a number and a 
string.  For example, this:

   void foo(double arg);
   void foo(DOMString arg);

is not valid WebIDL.

I think I've seen 3 requests in the last several months to lift this 
restriction.  The question is whether we should and if so what the 
behavior should end up being, from an idiomatic JS perspective.

First, the use cases:

1)  I can't recall what the first one was.  :(

2)  The second is that audio API has legacy constants that are integers 
and "new-style" constants that are strings and wants to have a property 
whose setter takes either one.  This _could_ be done with just strings, 
with the set of allowed values then looking something like "0", "1", 
"2", "foo", "bar", "baz" and an attempt to assign 0 auto-coercing to 
"0".  But that does work that seems unnecessary: creation of the string 
"0" from the number...  Ehsan, are there other issues with this approach 
too?

3)  The third one is IndexedDB, which allows primitive numbers and 
primitive strings (but not Number or String objects, note) as key 
values.  It also allows Arrays and Dates, but those are a separate 
concern.  IndexedDB treats 42 and "42" as different keys.  Right now it 
does this via using "any" in IDL and then defining the whole thing in 
terms of introspection of the original ES value involved.  This API 
seems pretty weird to me, at first glance, but there is quite a bit of 
existing library API precedent for treating String objects and primitive 
strings differently, as far as I can tell...  Checking for typeof == 
"string" is pretty common.

So even if we take IndexedDB as legacy, what should actually happen 
here?  People clearly _want_ to be doing this sort of overloading, but 
should they be if they want idiomatic APIs?

-Boris

Received on Saturday, 13 April 2013 20:37:22 UTC