Open
Bug 889014
Opened 11 years ago
Updated 2 years ago
Cannot hide one WebIDL overload behind a pref
Categories
(Core :: DOM: Core & HTML, defect, P5)
Tracking
()
NEW
People
(Reporter: ehsan.akhgari, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
See the attached patch, which tries to hide one overload of the AudioContext.createBuffer function behind a pref. This is what I get when I build this:
0:23.93 File "/Users/ehsanakhgari/moz/mozilla-central/config/pythonpath.py", line 56, in <module>
0:23.93 main(sys.argv[1:])
0:23.93 File "/Users/ehsanakhgari/moz/mozilla-central/config/pythonpath.py", line 48, in main
0:23.94 execfile(script, frozenglobals)
0:23.94 File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/GlobalGen.py", line 78, in <module>
0:23.94 main()
0:23.94 File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/GlobalGen.py", line 56, in main
0:23.94 parserResults = parser.finish()
0:23.94 File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 4645, in finish
0:23.94 production.finish(self.globalScope())
0:23.94 File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 629, in finish
0:23.94 member.resolve(self)
0:23.94 File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 2917, in resolve
0:23.94 IDLObjectWithIdentifier.resolve(self, parentScope)
0:23.94 File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 368, in resolve
0:23.94 self.identifier.resolve(parentScope, self)
0:23.94 File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 341, in resolve
0:23.94 scope.ensureUnique(self, object)
0:23.94 File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 250, in ensureUnique
0:23.94 object)
0:23.94 File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 552, in resolveIdentifierConflict
0:23.94 originalObject, newObject)
0:23.94 File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 270, in resolveIdentifierConflict
0:23.94 return originalObject.addOverload(newObject)
0:23.94 File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 2929, in addOverload
0:23.94 [self.location, method.location])
0:23.94 WebIDL.WebIDLError: error: Extended attributes differ on different overloads of <unresolved scope>::createBuffer, AudioContext.webidl line 25:4
0:23.94 AudioBuffer createBuffer(unsigned long numberOfChannels, unsigned long length, float sampleRate);
Does anybody know how to deal with this problem?
Reporter | ||
Updated•11 years ago
|
Blocks: ParisBindings
Comment 1•11 years ago
|
||
Yep. This is not supported given how overloads are represented right now. They're just combined into a single IDL method with a bunch of signatures; a signature is a return type and some arguments. There's no other per-signature information stored.
Supporting it is pretty nontrivial in general, given how complex overload resolution is already. We'd basically need to output two entirely different instances of overload resolution and call them based on a pref or something...
Maybe we can do something simpler specifically for the case when the prefable argument at the distinguishing index is an interface type; it should be simple to tweak the generated code to handle that if the data model were to preserve information about which signatures are prefable and which are not....
Comment 2•11 years ago
|
||
But the simpler alternative in this particular case is probably to just expose the signature unconditionally and then in the ArrayBuffer overload either throw if the pref is not set or convert the arraybuffer to an integer and call the other overload if you want to simulate the behavior of that overload really really not existing. Either one is doable, because dom::ArrayBuffer gives you access to the underlying JSObject.
Reporter | ||
Comment 3•11 years ago
|
||
We don't need to simulate anything since the semantics of these two functions are very different in fact. What would be the right exception to throw in this case?
Reporter | ||
Comment 4•11 years ago
|
||
I took a different approach in bug 889016. Feel free to resolve this as INVALID if it's not useful.
No longer blocks: 889016
Comment 5•6 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046
Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.
If you have questions, please contact :mdaly.
Priority: -- → P5
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•