Re: APIs that overload numbers and strings

On Apr 14, 2013, at 6:09 PM, Ehsan Akhgari wrote:

> 
> On Sat, Apr 13, 2013 at 7:39 PM, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
> > 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?
> 
> No I think you summarizes the issues here well.
>  
> This is interesting from an legacy compatibility perspective. If numeric strings and equivalent numbers always mean the same thing then simply saying the argument is a string would seem most straight forward.  I won't worry about the unnecessary string conversions. If most of the legacy values correspond to named constant attributes you may be able to respecify those constants as string values and no conversion is needed.  (they would still get converted to numbers if used in a computation).  Even if you can't change the constants, I won't worry about the conversion.  Note that in  JS someArray[5] also implies an implicit number to string conversion.
> 
> Changing the type of the attribute here to string doesn't seem like a great idea to me because it will hide the enumerated nature of the string used here.

But enumeration types don't actually exist in JS so I'm not sure what you think would be obscured.  Regardless, since an enumeration of is just a set of string values, the JS language type of an attribute (JS property) of that type is really string.

>  
> The bigger concern I have is if such values are retrieval as the value of some attribute or return value from some API calls. If so, you would need to change that result type to DOMString and there may be client code that isn't prepared to deal with that.  However, this may be another situation where auto-coercion from string to number saves the day. 
> 
> For retrieval we obviously cannot deal with multiple types, so for Web Audio we're going to return the new enumerated values.  The rationale here is that legacy code mostly needs to set these values and hopefully doesn't commonly depend on values read when retrieving them.

Like above, if you are using an enumeration as a type, then form the JS perspective you're talking about strings.

Allen