Re: Use of both numbered constants and strings

Quick question on this from an API user's perspective -

When I write an expression such as this -
	aPannerNode.panningModel = aPannerNode.EQUALPOWER;
the JS doesn't care what type the panningModel is,
as long as the types on either side of the assignment are compatible.

So would there be serious compatibility issues if implementors only
chose to use string enums and defined a property called EQUALPOWER
whose value is the string "equalpower" (instead of the integer 1)
for backward compatibility?

I'd expect most code uses such symbols instead of doing
	aPannerNode.panningModel = 1;

Best,
-Kumar	

On 23 Apr, 2013, at 11:14 AM, "Simon Pieters" <simonp@opera.com> wrote:

> On Tue, 23 Apr 2013 05:43:51 +0200, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:
> 
>>> From the perspective of Gecko as an implementer, I was really concerned
>> about these obsolete names in the spec, as have already started to hear
>> complaints about not supporting them in Firefox.  Note that these are all
>> style changes, and my position regarding backwards incompatible changes
>> regarding things that actually mean a change in the functionality supported
>> would be different.  But, given the fact that WebKit which was the only
>> other engine that was supporting Web Audio is unwilling to make backwards
>> incomoatble changes with regards to these names (and I think Blinks adopts
>> the same position), I don't believe that we are ever going to win this
>> fight with evangelizing to websites using the new names because the
>> majority of the Web Audio content is only ever tested against WebKit/Blink,
>> and most web developers learning about Web Audio will be reading outdated
>> material that was written around the time of the initial Web Audio launch,
>> which are all using the old names.  Therefore, we agreed that the best way
>> forward in order to get interoperable implementations is to require support
>> for the obsolete names under the title of alternate names.
> 
> So if implementors are not going to remove the old names, that leaves two options:
> 
> 1) Support both old and new names.
> 2) Support only the old names.
> 
> Has (2) been seriously considered? I think it is better to have one set of ugly names than one set of ugly names plus another set of less ugly names.
> 
> -- 
> Simon Pieters
> Opera Software
>

Received on Tuesday, 23 April 2013 06:06:03 UTC