Fixing enum names in Phobos

Jonathan M Davis jmdavisProg at gmx.com
Wed Aug 3 22:16:30 PDT 2011


On Sunday 31 July 2011 19:30:20 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?

So, does anyone actually have an opinion on this? Should we fix the names or 
not? One person has said that they're in favor of fixing the enum names, and 
pretty much everything else in this thread has been on what to do about 
renaming the ones which are keywords when properly camelcased.

If we're going to fix these enum names, we need to do it sooner rather than 
later. And I'd prefer some level of community buy-in before making breaking 
changes like that. At the moment, it looks like this post has been mostly 
ignored. Do you not care either way?

- Jonathan M Davis


More information about the Digitalmars-d mailing list