After some more discussion with Chris Wilson, I think it's reasonable to
have the create*() methods as statics that de-sugar to constructors that
bind instances to contexts, like so:
AudioContext.prototype.createAnalyser = function() {
return new AnanlyserNode({ context: this });
};
This doesn't remove the case for the constructors, though. And I think this
spec should be defining them ASAP.
On Thu, Jun 20, 2013 at 5:02 PM, Alex Russell <slightlyoff@google.com>wrote:
>
>
> On Thu, Jun 20, 2013 at 4:48 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>
>> On Thu, Jun 20, 2013 at 11:40 AM, Doug Schepers <schepers@w3.org> wrote:
>>
>>> 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.
>>>
>>
>> We can. But what's the point of having two ways to create each node?
>>
>
> To the extent that the group feels it can't rescind the create* methods,
> compatibility. Else, nothing. And these APIs should move to ONLY providing
> constructors.
>
Received on Tuesday, 25 June 2013 15:48:12 UTC