Re: Use of both numbered constants and strings

Den 2013-04-16 23:20:04 skrev Chris Rogers <crogers@google.com>:

>
>
>
> On Mon, Apr 15, 2013 at 10:36 AM, Simon Pieters <simonp@opera.com> wrote:
>> Hi
>>
>> https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html  
>> says
>>
>> [[
>> Some attributes taking constant values have changed during API review.  
>> The old way uses integer values, while the new way >>uses Web IDL  
>> string values. An implementation must support both integer and string  
>> values for setting these attributes:
>> // PannerNode constants for the .panningModel attribute
>>
>> // Old way
>> const unsigned short EQUALPOWER = 0;
>> const unsigned short HRTF = 1;
>> const unsigned short SOUNDFIELD = 2;
>>
>> // New way
>> enum PanningModelType {
>>  "equalpower",
>>  "HRTF",
>>  "soundfield"
>> };
>> ]]
>>
>> I'm not quite happy about the spec supporting both the legacy way and  
>> the new way. AFAIK no other API supports both. In >>HTML, for APIs that  
>> are widely used and thus can't have the numbered constants removed, the  
>> API only supports the legacy >>constants (can't come up with an example  
>> right now). For APIs that are not widely used yet and thus can be  
>> changed in >>incompatible ways, the APIs were changed to only support  
>> the strings (e.g. TextTrack.mode).
>>
>> Is Web Audio API widely used? Please consider choosing between "old  
>> way" and "new way". I think supporting both will be >>confusing for  
>> authors.
>
> Simon, yes we consider it widely used as there are both Chrome Apps  
> (Angry Birds, etc.), and iOS/Safari apps  which are >shipping.
>
> We had a very long discussion about this at the audio face-face meeting  
> this year, so this is what we have.

Jumping into discussion again...

I understand that there might be a problem with supporting old WebKit Web  
Audio apps, but I still fail to see why this kind of legacy support has to  
be part of the spec.

Isn't it true that legacy apps use the webkit prefixed version of the API?  
Why not keep all the "alternate" parts of the API in the prefixed name  
spaces, and let the un-prefixed (spec compliant) API entries be clean  
(i.e. only supporting the "new" way)? IMO, the same reasoning can be  
applied to section 20 in the spec too.

I'm sorry that I missed the f2f discussion on this, so could someone  
please explain why the current approach of supporting both the old and the  
new names/ways was selected?

/Marcus


>
> Chris
>
>
>
>>
>>
>>>> --
>> Simon Pieters
>> Opera Software
>>
>



-- 
Marcus Geelnard
Android Browser Developer
Opera Software ASA