Re: Use of both numbered constants and strings

On Mon, Apr 22, 2013 at 11:05 PM, Srikumar Karaikudi Subramanian <
srikumarks@gmail.com> wrote:

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

That's what I would have thought too, being a C/C++ programmer!  But, it
seems that most JS developers actually use the actual hard-coded numeric
value in actual practice instead of the symbolic constant value.



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