Review of std.net.isemail part 2

[Lars T. Kyllingstad]

On Wed, 30 Mar 2011 15:04:49 +0200, Don wrote:

> Lars T. Kyllingstad wrote:
>> On Wed, 30 Mar 2011 13:23:02 +0200, Don wrote:
>> 
>>> Jonathan M Davis wrote:
>>>> On 2011-03-30 01:27, Jacob Carlborg wrote:
>>>>> On 3/30/11 1:30 AM, Jesse Phillips wrote:
>>>>>> Jacob Carlborg Wrote:
>>>>>>> I've made a few minor changes:
>>>>>>>
>>>>>>> * Renamed EmailStatusCode.Off ->  None and On ->  Any * Added and
>>>>>>> clarified the documentation for EmailStatusCode.Any and None *
>>>>>>> Updated the documentation
>>>>>>>
>>>>>>> Github: https://github.com/jacob-carlborg/phobos/tree/isemail
>>>>>>> Docs: http://dl.dropbox.com/u/18386187/isemail.html
>>>>>>>
>>>>>>> --
>>>>>>> /Jacob Carlborg
>>>>>> I believe enum values are to be named lowercase first.
>>>>>> EmailStatusCode.any
>>>>> I don't know what the style guide says about enum members but if
>>>>> that's the case I'll change the names to begin with lowercase.
>>>> All names are camelcased.
>>> That's not true. ALLCAPS is relatively common in Phobos. There is
>>> absolutely no way PI is going to become pi.
>>>
>>>> All type names begin with an uppercase letter, and all variables
>>>> begin with a lowercase letter (with the possible exception of private
>>>> member variables beginning with _ - but what's private to a class or
>>>> struct isn't as critical as the public API regardless).
>>> That part is clear.
>>>
>>>  > enum values fall in the same camp as variables.
>>>
>>> I never heard that before, and it doesn't seem to be true throughout
>>> Phobos. Grepping for all enum declarations (there isn't very many of
>>> them actually), I found some which were like that, some which start
>>> with uppercase, and some which are all caps.
>>>
>>> I think you're assuming more concensus on style than has ever actually
>>> been discussed.
>> 
>> 
>> I think Andrei introduced the camelCase enum convention with his Phobos
>> overhaul back in 2.029.  All new modules, and most modules which have
>> seen major changes since then, follow it -- at least in the public API.
>> Examples include std.algorithm, std.datetime, std.file, std.getopt,
>> std.range and std.stdio.
>> 
>> I wouldn't mind if PI became pi -- I'd never dream of naming a variable
>> pi anyway, unless it's actually supposed to represent π.  Renaming E to
>> e, on the other hand, that's a lot worse.
>> 
>> -Lars
> 
> Hardly. The only examples I could find were algorithm: SwapStrategy,
> SortOutput
> range: traverseOptions, SearchPolicy
> There are many more which use other conventions, in other modules.

I don't intend to start a big debate about this, but I don't think you 
looked very hard.  All of the modules I mentioned follow the camelCase 
convention, and as far as I can tell, none have public enums that follow 
other conventions.

std.algorithm: OpenRight, EditOp, SwapStrategy, SortOutput

std.datetime: Month, DayOfWeek, AllowDayOverflow, Direction, PopFirst, 
AutoStart

std.file: SpanMode

std.getopt: config (actually not conventional, should be Config, but its 
members are still camelCased)

std.range: StoppingPolicy, TransverseOptions, SearchPolicy

std.stdio: KeepTerminator


> Note that manifest constants (eg, enum int XXX = value;) are completely
> different to enumerated types (eg, enum XXX { AAA, BBB, CCC } ) They're
> using a keyword in common, but they're quite different concepts.

I think a sensible rule is that types (and templates that evaluate to 
types) start with a capital letter, while values (and functions/templates 
that evaluate to values) are camelCased.

-Lars