W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2015

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 23 Jun 2015 08:33:40 +1000
Message-ID: <CAHp8n2n27tPB50VYH198ttMtG77WEE1gPeik9ZMQ=PZ-+b0DGw@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Tue, Jun 23, 2015 at 8:12 AM, Peter Thatcher <pthatcher@google.com> wrote:
> I like your rule, which I read as "we use CamelCase, except for that RTC
> thing at the beginning that we're stuck with".

As in other specs, having RTC capitalised at the beginning is somewhat
of a namespacing approach - "it's part of the RTC stuff". I actually
think that makes it quite readable.

> 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.

Wouldn't it be RTCDtmf according to the rule above?

> 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.

Why is a name change here so much harder? (Not that I'm worried - I'm
fine to keep it.)


> 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.
Received on Monday, 22 June 2015 22:34:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC