Fixing enum names in Phobos

[Alex Rønne Petersen]

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