Re: Naming conventions (Re: PR for adding RtpSender.transport)

I like your rule, which I read as "we use CamelCase, except for that RTC
thing at the beginning that we're stuck with".


I'm in favor of changing DTMFSender to be DtmfSender.  I don't think there
are any backwards compatibility issues with changing the type name (it's
just a search and replace in the spec and code base).  While we're at it,
can we change the event objects with "RTCDTMF" to "RtcDtmf" as well?  Might
as well be consistent.

The only change that would have some compatibility implications would be
the insertDTMF method.  As much as I would like that to be insertDtmf, I'm
willing to live with it being insertDTMF.

On Mon, Jun 22, 2015 at 1:27 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> On 06/21/2015 05:05 PM, Bernard Aboba wrote:
>
>> On Jun 21, 2015, at 1:30 AM, Harald Alvestrand <harald@alvestrand.no>
>> wrote:
>>
>>  So far, the WebRTC spec has mostly followed the Blink convention (RTC).
>>> Switching to the Google convention would be a major hassle, even though
>>> I find it more readable a lot of the time.
>>>
>> [BA] With respect to objects, the WebRTC spec mostly uses Google
>> convention (e.g. It is RTCRtpSender/RTCRtpReceiver, not
>> RTCRTPSender/RTCRTPReceiver).
>>
>>  Note: RTCDtmfSender, being a mixture, is not defensible under any of the
>>> conventions.
>>>
>> [BA] Then neither is RTCRtpSender/RTCRtpReceiver.
>>
> Seems we need a convention..... or more....
>
> the one rule I found (from 2012) is here: http://www.w3.org/TR/api-design/
>
> it says " The rules when one of those words is an acronym are not
> necessarily well established — follow your instinct (or try to avoid
> acronyms)."
>
> I'd be happy to go with a general rule that says "we use CamelCase always,
> except when it's RTC, and it's the first part of the name"..... but whether
> DTMF is worth changing is of course an interesting question.
>
>
>
>