-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better description of what AudioNode Constructors should do #1117
Comments
I suspect the sane way to define this would be to:
That's assuming the arguments to the two are meant to be interpreted the same way, of course. |
Since this is the same for each constructor, we specced it directly in the base class ( We did it the opposite way, the constructor calls the factory method, speccing how different things (attributes, |
That's totally not discoverable from reading the actual definition of an AudioNode subclass constructor. At the very least, those should link to the definition here. However....
There are several problems with doing it this way:
Consider this testcase:
This should alert true per WebIDL spec and sanity, but afaict false per current WebAudio spec. In the Firefox implementation, as far as I can tell from code inspection, it will alert true, due to details of our binding implementation, but after some GC it can start alerting false(!). And this didn't get caught in review, because the reviewer had now idea how this stuff should behave, based on the spec.
Specifically, consider this:
this should alert true, but per webaudio spec I don't see why it would, since the constructor is invoking some totally unrelated thing to create the object, which doesn't know about the
The sane way to do all this is to have a set of steps the constructor performs to initialize the object after creating it. The factory method can either invoke those same steps, by factoring them out into a spec algorithm invoked from both places, or call the constructor from the appropriate global. The latter is slightly preferable, because it centralizes the "how is the object actually created?" magic. |
To be clear, there is no problem in general with having some sort of centralized processing steps each constructor calls (though the particular steps in the spec have issues 1, 2, 3 above). But those steps need to be discoverable from the constructor definition. And in particular, the word "Constructor" in the IDL needs to link to those steps! |
Right. I'll reverse it here (make the factory method call the ctor). Thanks for the details, hopefully we can sort all this out soon. |
@bzbarsky, https://rawgit.com/padenot/web-audio-api/1117-constructors-take-two/index.html has a work in progress. Since this is going to be quite some work, it would be best to at least know if I'm going in the right direction here. Specifically:
Now the different problems:
|
Why? Why can't you just pass the type of dictionary involved, or even the dictionary itself, to the "factory method" algorithm from the various callsites? The "initializing the common part" text has some weird phrasing in step 1. Maybe you mean:
? Or:
I haven't had a chance yet to read the proposed changes, but as far as the problems being mentioned here...
Should that be "set the value associated with this attribute"? Does it have to be an object? But in general I think this looks sane.
This is not a new issue, right?
I'm not sure I follow...
This seems fine at first glance., but maybe I'm missing something?
Maybe something like this: "Call the FooNode constructor from the relevant global", where "relevant global" links to https://html.spec.whatwg.org/multipage/webappapis.html#concept-relevant-global It's a bit weird, because we want to pass an actual dictionary, not a JS object to be converted to a dictionary. @annevk do we have any better existing ideas on how this sort of thing should be structured? |
It's best not to invoke the constructor, since that is the public API. Just define an algorithm that creates and initializes the object. Maybe once IDL defines object creation in more detail there will be a better way. |
And call that algorithm from both the factory method and the constructor? |
Yeah. See https://url.spec.whatwg.org/#concept-urlsearchparams-new for instance. |
I've updated the text somewhat. There is now two algorithms (one for the ctor and one for the factory method), and they use the same an abstract operation to initialize the @domenic, I've been asked by Boris to ask you about which global to use for:
You can search for "AudioNodes can be created in two ways" in the link above to jump directly to the relevant text. Thanks, |
For what it's worth, the global of the object constructed by the constructor is already defined by the IDL spec: it's the global of the Realm of the constructor function. The only real question is what the factory method does. |
Right, the constructor is implicit. For the factory method, I guess we've settled on indeed using the same global/Realm as the object on which the method is being called, i.e. the relevant global/Realm of this BaseAudioContext object. |
Thanks both, I can finish this now. |
AudioNodes have two ways to be constructed: Constructors and Factory methods.
We should definitely describe better what the Constructors should do because sometimes, this is unclear.
If these Constructors are supposed to call factory methods, I suggest to see how each param should be passed.
The text was updated successfully, but these errors were encountered: