Re: Introduction of BaseAudioContext and broken prototype

Hmm. I feel like hasOwnProperty() is sort of a broken way to check for the
existence of a method, precisely because it is checking inheritance. It
seems like better practice to me to check if
typeof(AudioContext.prototype.createGain) == 'function'.

Not that we want to break anyone's code. I'm unsure of the best way to
proceed at the moment, and I guess this was a breaking change at some
level, which we didn't anticipate. I wonder if this refactoring issue has
come up with the TAG in the past.

I'm interested in hearing everyone's perspective. Perhaps we should add
this to Thursday's agenda.

Best,

.            .       .    .  . ...Joe

Joe Berkovitz
President
Noteflight LLC

+1 978 314 6271

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Tue, Oct 4, 2016 at 1:58 PM, Hongchan Choi <hongchan@google.com> wrote:

> Hello all,
>
> I would like to report an issue about the recent breakage in Chromium due
> to the newly introduced BaseAudioContext.
>
> I believe this is the spec decision we have made:
> https://github.com/WebAudio/web-audio-api/issues/1022
> https://github.com/WebAudio/web-audio-api/issues/308#
> issuecomment-149363285
>
> However, this change caused some issues in several WebAudio libraries that
> check the prototype properties on AudioContext with `hasOwnProperty()`
> method. For example, this will fail:
>
> AudioContext.prototype.hasOwnProperty('createGain');
>
> 1. Is this WG's mistake to overlook this breakage? If so, should we revert
> this spec change and have completely separate IDLs for AudioContext and
> OfflineAudioContext?
> 2. If the WG's decision still holds, how do we announce this change to
> developers?
> 3. Paul suggested that we might be able to avoid exposing this and have
> two separate classes in the implementation. Is this allowed from the TAG's
> perspective?
>
> Thanks.
>
> Best,
> Hongchan
>