Re: renaming updateIce

I have an automatic negative reaction to anything increasing complexity at
this point in time, and adding a builder object seems like complexity
increase.

pc.getConfiguration().setIceTransports("foo").apply()

doesn't seem that much better to me than

var cfg = pc.getConfiguration();
cfg.iceTransports = "foo";
pc.setConfiguration(cfg);





On Wed, Apr 30, 2014 at 10:27 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  On 30/04/2014 10:43 AM, Jan-Ivar Bruaroey wrote:
>
>
>
> I think setConfiguration(RTCConfiguration) is preferable in the sense that
> you don't want to end up with PeerConnection.getConfiguration() returning a
> value that doesn't actually correspond to the current PeerConnection state.
>
> If you use the Builder design pattern, you could do even better:
>
>   PeerConnection.getConfiguration().changeSomething().apply()
>
> where PeerConnection.getConfiguration() returns a copy-on-write
> configuration object and apply() updates the PeerConnection, otherwise the
> object is discarded and never used.
>
>
> Dictionaries already address the telescoping constructor problem, so while
> I'm a fan of the builder pattern, it seems redundant here.
>
>
> The Builder pattern allows you to implement copy-on-write. Dictionaries
> require you to always return a copy, regardless of whether it's used.
> The Builder is better suited to changing one or two properties and
> applying the same, all on a single line of code; whereas dictionaries
> require you to spread this out over multiple lines.
>
> I think Dictionaries are great for the initial configuration, but for
> deltas I think Builder does a better job. Technically speaking, we can do
> both:
>
>    1. PeerConnection's constructor or setConfiguration() can take a
>    dictionary for the initial configuration.
>    2. getConfiguration() can return a builder for reading existing values
>    and applying minor deltas.
>
>
> Gili
>