W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2016

Re: Introduction of BaseAudioContext and broken prototype

From: Joe Berkovitz <joe@noteflight.com>
Date: Tue, 4 Oct 2016 15:56:07 -0400
Message-ID: <CA+ojG-bvYsqtk4eX6bBRmhmLgzTpfBdm9Sc+QQb_TOzskZXojg@mail.gmail.com>
To: Hongchan Choi <hongchan@google.com>
Cc: Audio WG <public-audio@w3.org>
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.


.            .       .    .  . ...Joe

Joe Berkovitz
Noteflight LLC

+1 978 314 6271

49R Day Street
Somerville MA 02144

"Bring music to life"

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
Received on Tuesday, 4 October 2016 19:56:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 October 2016 19:56:37 UTC