Constructors (was: Sites using webkitAudioContext only)

Hi, folks-

Maybe someone could clear this up for me. Couldn't we just have both 
types of constructor?

Unlike method/keyword aliases and prefixed names, this doesn't seem like 
something that would be particularly harmful or confusing to developers, 
or too much effort to implement or maintain, and it solves both of the 
concerns (backwards compatibility, and platform consistency) that seem 
to be expressed.

What am I missing here?

Regards-
-Doug

On 6/20/13 11:30 AM, Ehsan Akhgari wrote:
> On Thu, Jun 20, 2013 at 11:14 AM, Chris Wilsonwrote:
>
>             As I think I previously mentioned, I actually don't think
>             constructors is a good idea here (as most of the nodes have
>             a direct relationship with the context).
>
>
>         You can just pass in the context to the constructor, so this is
>         not really a huge issue.
>
>
>     I fail to see how that's better.  You then have to define for each
>     constructor what happens if it's null, or invalid, ... all for what
>     to me is simply a stylistic change.  Am I missing some innate value
>     of this pattern?
>
>
> Yes, it is simply a stylistic change, sorry if I was not clear about
> this before.
>
>         It's true that we can standardize Web Audio with these C-style
>         creator APIs and things will work in practice, but we will end
>         up with a non-webby API.
>
>
>     I don't think this makes Web Audio "non-webby".  I use
>     document.createElement() all the time.
>
>
> document.createElement() is very old.  See things like creating events,
> blobs, XHR, WebSockets, ranges, speech API, Audio(), Image(), etc.  :-)
>
>         That's not a deal breaker, but we have the potential to fix this
>         problem now if all of the three engines implementing Web Audio
>         cooperate.  Otherwise, I don't have a lot of hope of this being
>         possible in a V2 of the spec -- that is, we might spec and
>         implement a better API, but the damage of the current API will
>         be done for everybody who has already learned and used the API,
>         and it will ripple through other web developers for some time.
>
>
>     I agree that this isn't something that could be pushed to v2.  I
>     don't see the value of it, however.
>
>
> There is some value in designing APIs which fit well with other APIs on
> the Web platform.  It's not the end of the world if Web Audio won't be
> such an API, but all else equal, we should make an effort to make it such.

Received on Thursday, 20 June 2013 15:40:23 UTC