Bug 17408 - (NodeCreation): Node creation syntax
(NodeCreation): Node creation syntax
Status: CLOSED INVALID
Product: AudioWG - OBSOLETE - Moved to Github
Classification: Unclassified
Component: Web Audio API - OBSOLETE - See Github
unspecified
PC All
: P2 normal
: TBD
Assigned To: This bug has no owner yet - up for the taking
This bug has no owner yet - up for the taking
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-05 12:37 UTC by Michael[tm] Smith
Modified: 2012-09-10 10:11 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael[tm] Smith 2012-06-05 12:37:46 UTC
Audio-ISSUE-26 (NodeCreation): Node creation syntax

http://www.w3.org/2011/audio/track/issues/26

Raised by: Marcus Geelnard
On product: 

Each node has its own create* method on the AudioContext object.

A common way is to use a single method taking a string argument giving the object name and an optional parameter object for object-specific parameters.

Examples: document.createElement() and canvas.getContext().

While semantically similar, using a single create* method is probably preferable over many different create* methods (e.g less namespace pollution, clearer extensibility mechanism and more consistent with other Web interfaces).
Comment 1 Olivier Thereaux 2012-06-07 15:11:46 UTC
Comment from Robert O'Callahan, 15 May 2012,

« I actually think the current set of methods is better. They're in the AudioContext so namespace pollution isn't a problem. Adding new methods is a perfectly adequate extension point. canvas.getContext() is a mess and being consistent with it is not a virtue. »
Comment 2 Philip Jägenstedt 2012-06-08 09:25:24 UTC
It seems like this provoked roc to blog:

http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html

However, MediaStream Processing's createProcessor looks like it's repeating the "getContext() mistake":

https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html#mediastream-extensions

That being said, I'm having a hard time forming a strong opinion on this issue.
Comment 3 Robert O'Callahan (Mozilla) 2012-06-08 09:43:28 UTC
(In reply to comment #2)
> It seems like this provoked roc to blog:
> 
> http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html

That is germane, but it isn't what provoked me to blog...

> However, MediaStream Processing's createProcessor looks like it's repeating the
> "getContext() mistake":
> 
> https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html#mediastream-extensions

Oops. Hoist by my own petard!

> That being said, I'm having a hard time forming a strong opinion on this issue.

I stand by my blog post.

(In reply to comment #0)
> A common way is to use a single method taking a string argument giving the
> object name and an optional parameter object for object-specific parameters.
> 
> Examples: document.createElement() and canvas.getContext().
> 
> While semantically similar, using a single create* method is probably
> preferable over many different create* methods (e.g less namespace pollution,
> clearer extensibility mechanism and more consistent with other Web interfaces).

document.createElement() is different because there's an infinite number of different HTML elements you can create, so a finite number of create methods can't work.

Also, "document" and especially "window" are such large and generic interfaces that adding dozens of new methods to them is undesirable. Canvas elements and AudioContexts don't have that problem.
Comment 4 Marcus Geelnard (Opera) 2012-06-12 06:36:38 UTC
Points taken. I especially agree that as an extension mechanism, checking the presence of an object property is better than having to create an object an check if it succeeded or not.
Comment 5 Olivier Thereaux 2012-09-10 10:11:22 UTC
No objection since June, closing.