Review of std.net.isemail part 2

[Jonathan M Davis]

On 2011-03-30 11:47, Jacob Carlborg wrote:
> On 2011-03-30 20:15, Don wrote:
> > Lars T. Kyllingstad wrote:
> >> 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
> > 
> > The point is this: we do NOT have a style guide.
> > We have consensus on a few things. Types start with a capital letter.
> > Functions are camelCased. Many other things haven't actually been
> > discussed and agreed to.
> > 
> > Note that simplistic rules are doomed to failure. For example, template
> > aliases can be either values or types.
> > 
> > Also, any attempt to use precedent is a disaster since Phobos began as a
> > complete mishmash of styles. In some cases people erroneously believed
> > there was a convention, and attempted to adhere to it, even though no
> > such convention existed.
> > 
> > We desperately need a style guide containing all the things which have
> > actually been agreed to (and equally importantly, nothing which hasn't).
> > The simplest thing to do would be to fix up the existing one on the
> > website which nobody follows.
> 
> So, should I change the enum members to start with lowercase or leave it
> like it is?

I would say to change it to start with lowercase. That's what all of the newer 
Phobos code does.

- Jonathan M Davis