This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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 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. »
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.
(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.
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.
No objection since June, closing.