Re: [Bug 17793] New: AudioNode.disconnect() needs to be able to disconnect only one connection

I see what you mean.  We could always define the defaults as -1, rather
than 0, and have that mean "remove any/all".

I'm inclined to make it easy to use in the single i/o case, since that is
90% of the API surface today.

On Thu, Jul 19, 2012 at 11:31 AM, Peter van der Noord <peterdunord@gmail.com
> wrote:

> I did some more thinking about this part:
>
>
> On Wed, Jul 18, 2012 at 2:24 AM, Peter van der Noord <
> peterdunord@gmail.com> wrote:
>
>> Ok, that's clear. But going back to what got us here, the suggested
>> disconnect function:
>>
>>  void disconnect(in [Optional] AudioNode destination, in [Optional]
>> > unsigned long output = 0)
>> >             raises(DOMException);
>>
>> ...doesnt seem like it can unambiguously handle all cases,
>>
>> nodeA.connect(nodeB, 0)    -> A out#0 to B in#0
>> nodeA.connect(nodeB, 1)    -> A out#0 to B in #1
>>
>> Supplying an output and a destinationnode is not enough to pinpoint any
>> of the two connections, you will *have* to supply the destination's input
>> index as well if you want to remove one (or do i think i'm understanding
>> this, while in fact i am not)
>>
>
> Heh.  Right you are, you would in fact have to (potentially) supply the
> destination's input
>
>
> I wanted to add that, in my opinion, the method should raise an exception
> when it's not unambigously clear what to disconnect. But, thinking
> further...this can't be done.
>
> Take the above connections as an example, and this most recently suggested
> disconnect method:
>
> node.disconnect(node = null, outputindex = 0, inputindex = 0) with all
> parameters optional.
>
> Now, let's say i want to remove the connection i made on the second line
> (A out#0 to B in#1). Let's also assume that i somehow forgot that the other
> connection going out of out#0 existed. I'd do:
>
> nodeA.disconnect(nodeB, 0);
>
> My thought was raising an exception here would be nice: "hey, you want to
> remove a connection from an output, but there are more connections there so
> i don't know which one to remove."
>
> But, since the optional third parameter (which defines the input#)
> defaults to 0, there is no way to throw an exception, because the other
> connection will simply be removed.
>
> And the method would react even differently when the first connection
> wasnt connected to input #0 but to #2. Again i'm forgetting there are two
> outgoing connections on output #0:
>
> nodeA.disconnect(nodeB, 0);
>
> Third parameter not supplied, defaults to 0, probably gives an error
> because there's nothing there on input #0.
>
> The fact that all params are optional doesnt help in my opinion, it leaves
> a lot of room for unnoticable mistakes. Does anyone else see this as a
> problem, or am i the only one? :)
>
> Peter
>
>
>
>
>