On 2011-08-04 07:16, Jonathan M Davis wrote:
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
On 8/4/11 12:16 AM, Jonathan M Davis wrote:
So, does anyone actually have an opinion on this? Should we fix the names or
not?
We should probably fix the names. A migration path is to simply keep
both names for a year or so and remove documentation for old names. For
example:
enum Variadic
On Thursday 04 August 2011 07:33:55 Andrei Alexandrescu wrote:
On 8/4/11 12:16 AM, Jonathan M Davis wrote:
So, does anyone actually have an opinion on this? Should we fix the
names or not?
We should probably fix the names. A migration path is to simply keep
both names for a year or so and
On Thursday 04 August 2011 08:59:11 Jonathan M Davis wrote:
On Thursday 04 August 2011 07:33:55 Andrei Alexandrescu wrote:
On 8/4/11 12:16 AM, Jonathan M Davis wrote:
So, does anyone actually have an opinion on this? Should we fix the
names or not?
We should probably fix the names. A
On 8/4/11 5:59 PM, Jonathan M Davis wrote:
I think that it would be far better to just fix the names immediately.
I'd argue not to touch std.socket though, this would unnecessarily break
code that will be broken again (hopefully) soon once std.socket gets
replaced.
David
On Thursday 04 August 2011 18:01:28 David Nadlinger wrote:
On 8/4/11 5:59 PM, Jonathan M Davis wrote:
I think that it would be far better to just fix the names immediately.
I'd argue not to touch std.socket though, this would unnecessarily break
code that will be broken again (hopefully)
On 8/4/11 10:59 AM, Jonathan M Davis wrote:
On Thursday 04 August 2011 07:33:55 Andrei Alexandrescu wrote:
On 8/4/11 12:16 AM, Jonathan M Davis wrote:
So, does anyone actually have an opinion on this? Should we fix the
names or not?
We should probably fix the names. A migration path is to
On 8/4/11 10:59 AM, Jonathan M Davis wrote:
On Thursday 04 August 2011 07:33:55 Andrei Alexandrescu wrote:
On 8/4/11 12:16 AM, Jonathan M Davis wrote:
So, does anyone actually have an opinion on this? Should we fix the
names or not?
We should probably fix the names. A migration path
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
How do you plan on camelCasing pure, nothrow, out, ref, etc?
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
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
On Monday 01 August 2011 08:26:26 Alex Rønne 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
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
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
On Monday 01 August 2011 10:00:01 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_
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,
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.
On Mon, 01 Aug 2011 05:56:22 +, %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.
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.
20 matches
Mail list logo
