Re: APIs that overload numbers and strings

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.


> 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.


Cheers,

--
Ehsan
<http://ehsanakhgari.org/>