W3C home > Mailing lists > Public > public-orca@w3.org > September 2013

Re: setXxxxxDescription() vs setters/properties [via ORCA - Object-RTC API Community Group]

From: Robin Raymond <robin@hookflash.com>
Date: Mon, 02 Sep 2013 12:10:00 -0400
Message-ID: <5224B858.7090301@hookflash.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
CC: public-orca <public-orca@w3.org>

I don't see how it complicates anything. It's a simple property 
container structure.

The reason to do it that way is that it makes cleaner APIs when you can 
keep things property based when they are simple property values.

A good summary:
http://msdn.microsoft.com/en-us/library/vstudio/ms229054(v=vs.100).aspx

In general, methods represent actions and properties represent data. 
Properties are meant to be used like fields, meaning that properties 
should not be computationally complex or produce side effects. When it 
does not violate the following guidelines, consider using a property, 
rather than a method, because less experienced developers find 
properties easier to use.




> Iñaki Baz Castillo <mailto:ibc@aliax.net>
> 2 September, 2013 11:53 AM
> 2013/8/30 Robin Raymond <robin@hookflash.com>
>
>
> Hi Robin, I insist:
>
> If we want connection.local and connection.remote then we must define
> what "local" and "remote" are, which means more spec complexity
> (IMHO). And honestly still I see no benefit in the approach you
> propose. Why is it better to require two lines instead of just one
> when we *always* need userFrag and password for connecting the remote?
>
> Maybe I miss something :)
>
>
> Robin Raymond <mailto:robin@hookflash.com>
> 30 August, 2013 9:19 AM
>
>
> Wanted to address this:
>
> myConnection.remote.ice.userFrag = XXXXX;
> myConnection.remote.ice.passwd = XXXXX;
>
> myConnection.connect();
>
>
> There's also a different way to do it so you aren't in an intermediate 
> state (half set):
>
> myConnection.remote.ice = {userFrag: XXXXX; passwd: XXXXX;};
> myConnection.connect();
>
> Just keep that in mind when you are doing the API that getter / 
> setters can take entire objects, not just single one at a time settings.
>
> I think with any API we do, we should remember we'll have to "shim" it 
> over top of the ugly SDP API, so we have to make sure whatever we do 
> can be wired appropriately.
>
> -Robin
>
> PS. Sorry for the late reply, been awfully sick in the past week.
>
>
> Iñaki Baz Castillo <mailto:ibc@aliax.net>
> 28 August, 2013 4:54 AM
> Current API defines some methods that expect an Object as argument, or 
> that
> return an Object. For example, when Alice needs to signal Bob that she 
> will send
> an Opus audio track with payload-id=98 and SSRC=1234, something like 
> this should
> be coded: // Alice gets her sending track description/details and 
> signals them
> to Bob: var rtcTrack = rtcConnection.track(audioMediaStreamTrack);
> signalingChannel.send(JSON.stringify({ [...]
>
>
>
> ----------
>
> This post sent on ORCA - Object-RTC API Community Group
>
>
>
> 'setXxxxxDescription() vs setters/properties'
>
> http://www.w3.org/community/orca/2013/08/28/setxxxxxdescription-vs-settersproperties/
>
>
>
> Learn more about the ORCA - Object-RTC API Community Group:
>
> http://www.w3.org/community/orca
>
>
>
Received on Monday, 2 September 2013 16:10:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:21 UTC