www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Fixing enum names in Phobos

reply Jonathan M Davis <jmdavisProg gmx.com> writes:
Okay. Per the current naming conventions in Phobos, enum values are supposed 
to be camelcased just like any other variable. The enum _type_ is pascal cased 
just like any other user-defined type, but the values are camelcased. A number 
of the older parts of Phobos do not follow this convention. Ideally, this 
would be fixed so that Phobos can be more consistent, and for the most part, 
those in this newsgroup have agreed that they'd prefer to have Phobos fixed to 
be more consistent and put up with the temporary code breakage rather than 
have it permanently inconsistent. The question is whether it's worth it in 
this case. The enums that I'm aware of in Phobos which are not properly 
camelcased are:

std.compiler.Vendor: DigitalMars (and the recently added GNU, LLVM, and 
Unknown).

std.mmfile.MmFile.Mode: Read, ReadWriteNew, ReadWrite, ReadCopyOnWrite

std.JSON_TYPE: STRING, INTEGER, FLOAT, OBJECT, ARRAY, TRUE, FALSE, NULL

std.socket.AddressFamily: UNSPEC, UNIX, INET, IPX, APPLETALK

std.socket.SocketType: STREAM, DGRAM, RAW, RDM, SEQPACKET

std.socket.ProtocolType: IP, ICMP, IGMP, GGP, TCP, PUP, UDP, IDP, IPV6

std.socket.SocketShutdown: RECEIVE, SEND, BOTH

std.socket.SocketFlags: NONE, OOB, PEEK, DONTROUTE

std.socket.SocketOptionLevel: SOCKET, IP, ICMP, IGMP, GGP, TCP, PUP, UDP, IDP, 
IPV6

std.socket.OptionLevel: DEBUG, BROADCAST, REUSEADDR, LINGER, OOBINLINE, 
SNDBUF, RCVBUF, DONTROUTE, SENDTIMEO, RCVTIMEO, TCP_NODELAY, 
IPV6_UNICAST_HOPS, IPV6_MULTICAST_IF, IPV6_MULTICAST_LOOP, IPV6_JOIN_GROUP, 
IPV6_LEAVE_GROUP

std.stream.BOM: UTF8, UTF16LE, UTF16BE, UTF32LE, UTF32BE

std.system.Endian: BigEndian, LittleEndian

std.traits.ParameterStorageClass: NONE, SCOPE, OUT, REF, LAZY

std.traits.FunctionAttribute: NONE, PURE, NOTHROW, REF, PROPERTY, TRUSTED, 
SAFE

std.traits.Variadic: NO, C, D, TYPESAFE

std.xml.DecodeMode: NONE, LOOSE, STRICT

std.xml.TagType: START, END, EMPTY


So, the question is. Which, if any, should we fix to be camelcased?

It will break code to fix any of these. We can't really go through a clean 
deprecation process on these without outright replacing the enum types 
themselves, which would have a nasty cascading effect through everything that 
uses them. The spellchecker will catch the changes easily, and so fixing any 
code that uses them will be easy, but it will still be annoying. So, is this 
temporary breakage worth the gain in consistency? And if so, for which ones? 
Or should we just leave them as-is?

- Jonathan M Davis
Jul 31 2011
next sibling parent reply %u <wfunction hotmail.com> writes:
How do you plan on camelCasing pure, nothrow, out, ref, etc?
Jul 31 2011
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Aug 1, 11 13:56, %u wrote:

 How do you plan on camelCasing pure, nothrow, out, ref, etc?


pure_, nothrow_, out_, ref_

pureAttribute, nothrowAttribute, outAttribute, refAttribute
Aug 01 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 01 August 2011 15:02:54 KennyTM~ wrote:

 On Aug 1, 11 13:56, %u wrote:

 How do you plan on camelCasing pure, nothrow, out, ref, etc?


 
 pure_, nothrow_, out_, ref_
 
 pureAttribute, nothrowAttribute, outAttribute, refAttribute


Yeah. Something like that. You'd have to add a prefix or a suffix to them all. 
But the fact that you can't actually just camelcase them might be a good 
argument for leaving them as-is. If we're willing to change them though, a 
simple prefix or suffix shouldn't be all that big a deal - especially if it's 
shorter rather than longer.

- Jonathan M Davis
Aug 01 2011
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-08-2011 09:39, Jonathan M Davis wrote:

 On Monday 01 August 2011 15:02:54 KennyTM~ wrote:

 On Aug 1, 11 13:56, %u wrote:

 How do you plan on camelCasing pure, nothrow, out, ref, etc?


 pure_, nothrow_, out_, ref_

 pureAttribute, nothrowAttribute, outAttribute, refAttribute


 Yeah. Something like that. You'd have to add a prefix or a suffix to them all.
 But the fact that you can't actually just camelcase them might be a good
 argument for leaving them as-is. If we're willing to change them though, a
 simple prefix or suffix shouldn't be all that big a deal - especially if it's
 shorter rather than longer.

 - Jonathan M Davis


I may very well be biased since I come from .NET land, but I have to 
say, camel case enum member names do seem a bit weird to me. While enum 
members could be argued to be fields, they certainly don't have those 
semantics, so maybe pascal case might not be so bad?

- Alex
Aug 01 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 01 August 2011 10:00:01 Alex R=C3=B8nne Petersen wrote:

 On 01-08-2011 09:39, Jonathan M Davis wrote:

 On Monday 01 August 2011 15:02:54 KennyTM~ wrote:

 On Aug 1, 11 13:56, %u wrote:

 How do you plan on camelCasing pure, nothrow, out, ref, etc?


=20
 pure_, nothrow_, out_, ref_
=20
 pureAttribute, nothrowAttribute, outAttribute, refAttribute


=20
 Yeah. Something like that. You'd have to add a prefix or a suffix t=




o

 them all. But the fact that you can't actually just camelcase them
 might be a good argument for leaving them as-is. If we're willing t=




o

 change them though, a simple prefix or suffix shouldn't be all that=




 big

 a deal - especially if it's shorter rather than longer.
=20
 - Jonathan M Davis


=20
 I may very well be biased since I come from .NET land, but I have to
 say, camel case enum member names do seem a bit weird to me. While en=


um

 members could be argued to be fields, they certainly don't have those=



 semantics, so maybe pascal case might not be so bad?


Camelcasing for enum values is what was decided upon, and all of the ne=
wer=20
Phobos stuff follows it. It's just some of the older stuff (primarily s=
tuff which=20
was around in D1, I believe) which doesn't follow the correct naming=20=

conventions for enums. We may very well decide that it's not worth fixi=
ng these=20
enums to follow the correct naming conventions for Phobos, but the corr=
ect=20
naming conventions have already been decided on. Enum types are pascal =
cased,=20
and their values are camelcased. That's not up for discussion at this p=
oint.=20
What _is_ up for discussion is whether fixing these enums to follow Pho=
bos'=20
naming conventions is worth the code breakage that it will cause.

- Jonathan M Davis
Aug 01 2011
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Aug 1, 11 16:00, Alex Rønne Petersen wrote:

 On 01-08-2011 09:39, Jonathan M Davis wrote:

 On Monday 01 August 2011 15:02:54 KennyTM~ wrote:

 On Aug 1, 11 13:56, %u wrote:

 How do you plan on camelCasing pure, nothrow, out, ref, etc?


 pure_, nothrow_, out_, ref_

 pureAttribute, nothrowAttribute, outAttribute, refAttribute


 Yeah. Something like that. You'd have to add a prefix or a suffix to
 them all.
 But the fact that you can't actually just camelcase them might be a good
 argument for leaving them as-is. If we're willing to change them
 though, a
 simple prefix or suffix shouldn't be all that big a deal - especially
 if it's
 shorter rather than longer.

 - Jonathan M Davis


 I may very well be biased since I come from .NET land, but I have to
 say, camel case enum member names do seem a bit weird to me. While enum
 members could be argued to be fields, they certainly don't have those
 semantics, so maybe pascal case might not be so bad?

 - Alex


In .NET (almost) everything is CapitalCamelCased :D

Anyway, the rule of thumb is
  - Things are CapitalCamelCased if they can create a type
  - Otherwise, they are smallLetterCamelCased

Enum members aren't types, so they shouldn't be CapitalCamelCased.
Aug 01 2011
parent Mehrdad <wfunction hotmail.com> writes:
On 8/1/2011 2:15 AM, KennyTM~ wrote:

 In .NET (almost) everything is CapitalCamelCased :D


lol, it's called "PascalCased". :P

+1 for PascalCasing. It solves the keyword-ness issue.
Aug 01 2011
prev sibling parent Michal Minich <michal.minich gmail.com> writes:
On Mon, 01 Aug 2011 05:56:22 +0000, %u wrote:


 How do you plan on camelCasing pure, nothrow, out, ref, etc?


simply add exception to the camelCase rule: if word is keyword, use 
PascalCase. 

IMO, easier to remember and to the eyes than any kind of ad-hoc pre/sufix.
Aug 01 2011
prev sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-08-2011 04:30, Jonathan M Davis wrote:

 Okay. Per the current naming conventions in Phobos, enum values are supposed
 to be camelcased just like any other variable. The enum _type_ is pascal cased
 just like any other user-defined type, but the values are camelcased. A number
 of the older parts of Phobos do not follow this convention. Ideally, this
 would be fixed so that Phobos can be more consistent, and for the most part,
 those in this newsgroup have agreed that they'd prefer to have Phobos fixed to
 be more consistent and put up with the temporary code breakage rather than
 have it permanently inconsistent. The question is whether it's worth it in
 this case. The enums that I'm aware of in Phobos which are not properly
 camelcased are:

 std.compiler.Vendor: DigitalMars (and the recently added GNU, LLVM, and
 Unknown).

 std.mmfile.MmFile.Mode: Read, ReadWriteNew, ReadWrite, ReadCopyOnWrite

 std.JSON_TYPE: STRING, INTEGER, FLOAT, OBJECT, ARRAY, TRUE, FALSE, NULL

 std.socket.AddressFamily: UNSPEC, UNIX, INET, IPX, APPLETALK

 std.socket.SocketType: STREAM, DGRAM, RAW, RDM, SEQPACKET

 std.socket.ProtocolType: IP, ICMP, IGMP, GGP, TCP, PUP, UDP, IDP, IPV6

 std.socket.SocketShutdown: RECEIVE, SEND, BOTH

 std.socket.SocketFlags: NONE, OOB, PEEK, DONTROUTE

 std.socket.SocketOptionLevel: SOCKET, IP, ICMP, IGMP, GGP, TCP, PUP, UDP, IDP,
 IPV6

 std.socket.OptionLevel: DEBUG, BROADCAST, REUSEADDR, LINGER, OOBINLINE,
 SNDBUF, RCVBUF, DONTROUTE, SENDTIMEO, RCVTIMEO, TCP_NODELAY,
 IPV6_UNICAST_HOPS, IPV6_MULTICAST_IF, IPV6_MULTICAST_LOOP, IPV6_JOIN_GROUP,
 IPV6_LEAVE_GROUP

 std.stream.BOM: UTF8, UTF16LE, UTF16BE, UTF32LE, UTF32BE

 std.system.Endian: BigEndian, LittleEndian

 std.traits.ParameterStorageClass: NONE, SCOPE, OUT, REF, LAZY

 std.traits.FunctionAttribute: NONE, PURE, NOTHROW, REF, PROPERTY, TRUSTED,
 SAFE

 std.traits.Variadic: NO, C, D, TYPESAFE

 std.xml.DecodeMode: NONE, LOOSE, STRICT

 std.xml.TagType: START, END, EMPTY


 So, the question is. Which, if any, should we fix to be camelcased?

 It will break code to fix any of these. We can't really go through a clean
 deprecation process on these without outright replacing the enum types
 themselves, which would have a nasty cascading effect through everything that
 uses them. The spellchecker will catch the changes easily, and so fixing any
 code that uses them will be easy, but it will still be annoying. So, is this
 temporary breakage worth the gain in consistency? And if so, for which ones?
 Or should we just leave them as-is?

 - Jonathan M Davis


I'm personally a great fan of consistency and would gladly fix my code 
if it means the standard library would be cleaned up.

As for std.compiler.Vendor: I'm not sure if renaming these is a good 
idea. On one hand, there's consistency, but on the other hand, you'd 
probably want actual project/product/company names like that to be 
spelled correctly... That's why I just followed the pascal case 
convention in my patches.

- Alex
Jul 31 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 01 August 2011 08:26:26 Alex R=C3=B8nne Petersen wrote:

 As for std.compiler.Vendor: I'm not sure if renaming these is a good
 idea. On one hand, there's consistency, but on the other hand, you'd
 probably want actual project/product/company names like that to be
 spelled correctly... That's why I just followed the pascal case
 convention in my patches.


That's a case where there's a decent argument for not camelcasing them =
-=20
though Unknown should probably be changed to unknown. And since it's br=
and=20
new, it wouldn't even break any code to do that. Though of course, ther=
e's=20
still the issue of whether or not std.compiler should be deprecated in =
favor=20
of just using core.rt.compiler. But regardless of where the enum ends u=
p, the=20
naming issue is still the same.

- Jonathan M Davis
Aug 01 2011