www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Allocators/region allocator proposal overhaul

reply dsimcha <dsimcha yahoo.com> writes:
When I initially created my allocators proposal, I figured wrongly that 
the community would be most interested in seeing a few examples of 
allocators and that a more formal specification of the allocator 
interface wasn't terribly important yet.  I was wrong, so I got off my 
butt and wrote a more formal specification.  I also made a few other 
important changes to my allocators proposal:

1.  DynamicAllocator allows a struct or class that conforms to the 
structural allocator interface to be turned into a runtime interface 
with virtual functions, etc.  The reason for this trick instead of just 
making Allocator a "virtual" interface is to allow scoped allocators, 
allocators with value semantics, allocators with reference counting, 
etc. and only live within the constraints of the virtual function world 
when absolutely necessary.  One examples of where the virtual function 
world is a severe constraint is the templated functions create, 
newArray, uninitializedArray and array.  These were simply left out of 
the DynamicAllocator.  Another is the ugliness and unsafety of using the 
DynamicAllocator interface with RegionAllocator, as RegionAllocator's 
scoped semantics create a severe impedance mismatch.

2.  I added create(T) for creating new class and struct instances on an 
allocator.

3.  I cleaned up the documentation of RegionAllocator according to 
Andrei's suggestions.  I double-checked and freeIsChecked, etc. are 
enums.  DDoc just doesn't reflect this.

4.  Various fixes for small bugs pointed out by the community.

5.  Noted that finalizers/destructors are never automatically called 
when RegionAllocator-allocated memory gets freed, because the 
bookkeeping burden of this would be unacceptable and it would prevent 
O(1) freeing.  RegionAllocator is such an unsafe performance hack anyhow 
that I see very little wrong with "buyer beware" here.  Besides, most 
use cases for it (at least most of mine) are allocating temporary arrays 
of primitives and containers would use the lower-level DynamicAllocator 
interface.  YMMV.

6.  I did **not** change the documentation of the relationship between 
RegionAllocatorStack and RegionAllocator because I just don't see a good 
way to do it.  I'm open to suggestions.

7.  std.regionallocator -> std.allocators.region, etc.

8.  The high-level, templated allocator functions now have a default 
implementation in terms of lower-level allocator functionality, provided 
by the TypedAllocatorMixin mixin in std.allocators.allocator.  The idea 
is that an allocator may have better ways of accomplishing this stuff, 
but this mixin is usually a reasonable default and will avoid code 
duplication across allocators.  I'm leery of including it in the 
DynamicAllocator interface, though, because for some allocators it's 
just plain wrong.  For example, the default array() implementation just 
plain wouldn't work with RegionAllocator for huge ranges.

Code:

https://github.com/dsimcha/TempAlloc/tree/master/std/allocators

Docs:
http://cis.jhu.edu/~dsimcha/d/phobos/std_allocators_allocator.html
http://cis.jhu.edu/~dsimcha/d/phobos/std_allocators_gc.html
http://cis.jhu.edu/~dsimcha/d/phobos/std_allocators_region.html
Sep 11 2011
next sibling parent reply "Masahiro Nakagawa" <repeatedly gmail.com> writes:
On Mon, 12 Sep 2011 01:51:02 +0900, dsimcha <dsimcha yahoo.com> wrote:

 8.  The high-level, templated allocator functions now have a default  
 implementation in terms of lower-level allocator functionality, provided  
 by the TypedAllocatorMixin mixin in std.allocators.allocator.  The idea  
 is that an allocator may have better ways of accomplishing this stuff,  
 but this mixin is usually a reasonable default and will avoid code  
 duplication across allocators.  I'm leery of including it in the  
 DynamicAllocator interface, though, because for some allocators it's  
 just plain wrong.  For example, the default array() implementation just  
 plain wouldn't work with RegionAllocator for huge ranges.

I think Default(Templated)AllocatorFunctions are better than TypedAllocatorMixin. TypedAllocator is not clear for me. I will read documents and codes later.
Sep 11 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Masahiro Nakagawa (repeatedly gmail.com)'s article
 On Mon, 12 Sep 2011 01:51:02 +0900, dsimcha <dsimcha yahoo.com> wrote:
 8.  The high-level, templated allocator functions now have a default
 implementation in terms of lower-level allocator functionality, provided
 by the TypedAllocatorMixin mixin in std.allocators.allocator.  The idea
 is that an allocator may have better ways of accomplishing this stuff,
 but this mixin is usually a reasonable default and will avoid code
 duplication across allocators.  I'm leery of including it in the
 DynamicAllocator interface, though, because for some allocators it's
 just plain wrong.  For example, the default array() implementation just
 plain wouldn't work with RegionAllocator for huge ranges.

than TypedAllocatorMixin. TypedAllocator is not clear for me. I will read documents and codes later.

If you mean just making functions like T newArray(Allocator)(Allocator allocator, size_t size), etc., I've mentioned before that having the type available to the allocator is often useful and therefore these defaults need to be overrideable. Otherwise, please clarify.
Sep 11 2011
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from dsimcha (dsimcha yahoo.com)'s article
 == Quote from Masahiro Nakagawa (repeatedly gmail.com)'s article
 On Mon, 12 Sep 2011 01:51:02 +0900, dsimcha <dsimcha yahoo.com> wrote:
 8.  The high-level, templated allocator functions now have a default
 implementation in terms of lower-level allocator functionality, provided
 by the TypedAllocatorMixin mixin in std.allocators.allocator.  The idea
 is that an allocator may have better ways of accomplishing this stuff,
 but this mixin is usually a reasonable default and will avoid code
 duplication across allocators.  I'm leery of including it in the
 DynamicAllocator interface, though, because for some allocators it's
 just plain wrong.  For example, the default array() implementation just
 plain wouldn't work with RegionAllocator for huge ranges.

than TypedAllocatorMixin. TypedAllocator is not clear for me. I will read documents and codes later.

size_t size), etc., I've mentioned before that having the type available to the allocator is often useful and therefore these defaults need to be overrideable. Otherwise, please clarify.

Oh wait a minute, do you just mean the name of the mixin template? If so, I completely agree that your suggested name is better.
Sep 11 2011
prev sibling parent travert phare.normalesup.org (Christophe) writes:
dsimcha , dans le message (digitalmars.D:144293), a écrit :
 If you mean just making functions like T newArray(Allocator)(Allocator
allocator,
 size_t size), etc., I've mentioned before that having the type available to the
 allocator is often useful and therefore these defaults need to be overrideable.
 Otherwise, please clarify.

Maybe something like: auto newArray(T, Allocator)(Allocator allocator, size_t size) if (is(typeof(allocator.newArray!T(size))==T[]) { return allocator.newArray!T(size); }
Sep 12 2011
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from dsimcha (dsimcha yahoo.com)'s article
 8.  The high-level, templated allocator functions now have a default
 implementation in terms of lower-level allocator functionality, provided
 by the TypedAllocatorMixin mixin in std.allocators.allocator.  The idea
 is that an allocator may have better ways of accomplishing this stuff,
 but this mixin is usually a reasonable default and will avoid code
 duplication across allocators.  I'm leery of including it in the
 DynamicAllocator interface, though, because for some allocators it's
 just plain wrong.  For example, the default array() implementation just
 plain wouldn't work with RegionAllocator for huge ranges.

I just realized that the fact that this is mixed into RegionAllocator didn't make it into the DDoc anywhere. Is there any easy way to get DDoc to document that a mixin template has been mixed into a class/struct? I.e.: struct Foo { /// Document that this is mixed in. mixin SomeMixin; }
Sep 11 2011
parent Michal Minich <michal.minich gmail.com> writes:
V Sun, 11 Sep 2011 19:25:41 +0000, dsimcha wrote:

 Is there any easy way to getDDoc to document that a mixin template has 
 been mixed into a class/struct?  I.e.:
 
 struct Foo {
     /// Document that this is mixed in.
     mixin SomeMixin;
 }

Currently none. http://d.puremagic.com/issues/show_bug.cgi?id=648
Sep 12 2011
prev sibling next sibling parent "Masahiro Nakagawa" <repeatedly gmail.com> writes:
On Mon, 12 Sep 2011 04:37:17 +0900, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from dsimcha (dsimcha yahoo.com)'s article
 == Quote from Masahiro Nakagawa (repeatedly gmail.com)'s article
 On Mon, 12 Sep 2011 01:51:02 +0900, dsimcha <dsimcha yahoo.com> wrote:
 8.  The high-level, templated allocator functions now have a default
 implementation in terms of lower-level allocator functionality,  


 by the TypedAllocatorMixin mixin in std.allocators.allocator.  The  


 is that an allocator may have better ways of accomplishing this  


 but this mixin is usually a reasonable default and will avoid code
 duplication across allocators.  I'm leery of including it in the
 DynamicAllocator interface, though, because for some allocators it's
 just plain wrong.  For example, the default array() implementation  


 plain wouldn't work with RegionAllocator for huge ranges.

than TypedAllocatorMixin. TypedAllocator is not clear for me. I will read documents and codes later.

allocator, size_t size), etc., I've mentioned before that having the type available to the allocator is often useful and therefore these defaults need to be overrideable. Otherwise, please clarify.

Oh wait a minute, do you just mean the name of the mixin template? If so, I completely agree that your suggested name is better.

Yes. I mentioned the name of mixin template.
Sep 11 2011
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sun, 11 Sep 2011 19:51:02 +0300, dsimcha <dsimcha yahoo.com> wrote:

 https://github.com/dsimcha/TempAlloc/tree/master/std/allocators

I'm thinking of adjusting std.zlib functions/classes to take an optional allocator parameter (since currently its heap allocations are a huge target for false pointers). What should the default allocator be? Perhaps std.allocators.gc should have a static default GCAllocator instance? -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Sep 14 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Vladimir Panteleev (vladimir thecybershadow.net)'s article
 On Sun, 11 Sep 2011 19:51:02 +0300, dsimcha <dsimcha yahoo.com> wrote:
 https://github.com/dsimcha/TempAlloc/tree/master/std/allocators

allocator parameter (since currently its heap allocations are a huge target for false pointers). What should the default allocator be? Perhaps std.allocators.gc should have a static default GCAllocator instance?

May be a good idea. In fact, just because of GCAllocator's status as the obvious choice for a default allocator, maybe there should be two enums: (feel free to suggest better names) ScanningGcAllocator and NonScanningGcAllocator. These would provide standardized, self-documenting defaults.
Sep 14 2011
parent dsimcha <dsimcha yahoo.com> writes:
On 9/14/2011 5:24 PM, Vladimir Panteleev wrote:
 Tiny nitpick: case of "GC" in type/enum names should probably match for
 consistency.

Good point. Do we even have a convention for acronyms in variable/type names? If so is it GcAllocator or GCAllocator?
Sep 14 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thu, 15 Sep 2011 00:14:53 +0300, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Vladimir Panteleev (vladimir thecybershadow.net)'s article
 On Sun, 11 Sep 2011 19:51:02 +0300, dsimcha <dsimcha yahoo.com> wrote:
 https://github.com/dsimcha/TempAlloc/tree/master/std/allocators

allocator parameter (since currently its heap allocations are a huge target for false pointers). What should the default allocator be? Perhaps std.allocators.gc should have a static default GCAllocator instance?

May be a good idea. In fact, just because of GCAllocator's status as the obvious choice for a default allocator, maybe there should be two enums: (feel free to suggest better names) ScanningGcAllocator and NonScanningGcAllocator. These would provide standardized, self-documenting defaults.

Sounds great :) I see scanForPointers only affects the allocate method, so it won't affect code using typed allocators. Tiny nitpick: case of "GC" in type/enum names should probably match for consistency. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Sep 14 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, September 14, 2011 15:36 dsimcha wrote:
 On 9/14/2011 5:24 PM, Vladimir Panteleev wrote:
 Tiny nitpick: case of "GC" in type/enum names should probably match for
 consistency.

Good point. Do we even have a convention for acronyms in variable/type names? If so is it GcAllocator or GCAllocator?

We haven't been entirely consistent. For instance, we have UtfException, but _every_ other case of utf in the code is either utf (at the beginning of a function) or UTF (I have a pull request which includes fixing the casing on UtfException to match everything else). Given the choice, I'd definitely say that GC should be used and not Gc, and everywhere in Phobos where I've created a function which had an acronym in it, that's what I've done, but without going through the whole code base, I don't know which convention is more common (other than the case of Utf where I did go looking; it's easier when you know what the acronym is rather than looking for _all_ acronyms). I don't think that acronyms have been all that common in general though. - Jonathan M Davis
Sep 14 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Jonathan M Davis wrote:
 On Wednesday, September 14, 2011 15:36 dsimcha wrote:
 On 9/14/2011 5:24 PM, Vladimir Panteleev wrote:
 Tiny nitpick: case of "GC" in type/enum names should probably match for
 consistency.

Good point. Do we even have a convention for acronyms in variable/type names? If so is it GcAllocator or GCAllocator?

We haven't been entirely consistent. For instance, we have UtfException, but _every_ other case of utf in the code is either utf (at the beginning of a function) or UTF (I have a pull request which includes fixing the casing on UtfException to match everything else). Given the choice, I'd definitely say that GC should be used and not Gc, and everywhere in Phobos where I've created a function which had an acronym in it, that's what I've done, but without going through the whole code base, I don't know which convention is more common (other than the case of Utf where I did go looking; it's easier when you know what the acronym is rather than looking for _all_ acronyms). I don't think that acronyms have been all that common in general though.

When I had first glance at GCAllocator I observed this as well. I believe GcAlloctor is the better way to camelize it even though druntime has a class GC. It's easier to read for me, consider XMLToHTMLConverter vs. XmlToHtmlConverter or worse XMLHTMLConverter vs. XmlHtmlConverter. See http://stackoverflow.com/questions/1176950/acronyms-in-camel-back In sum I'd like to follow Java convention. I can also live with GCAllocator if that's more consistent with the current style. But it should definitely be fixed in the style guide. Jens
Sep 14 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, September 14, 2011 16:12 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Wednesday, September 14, 2011 15:36 dsimcha wrote:
 On 9/14/2011 5:24 PM, Vladimir Panteleev wrote:
 Tiny nitpick: case of "GC" in type/enum names should probably match
 for consistency.

Good point. Do we even have a convention for acronyms in variable/type names? If so is it GcAllocator or GCAllocator?

We haven't been entirely consistent. For instance, we have UtfException, but _every_ other case of utf in the code is either utf (at the beginning of a function) or UTF (I have a pull request which includes fixing the casing on UtfException to match everything else). Given the choice, I'd definitely say that GC should be used and not Gc, and everywhere in Phobos where I've created a function which had an acronym in it, that's what I've done, but without going through the whole code base, I don't know which convention is more common (other than the case of Utf where I did go looking; it's easier when you know what the acronym is rather than looking for _all_ acronyms). I don't think that acronyms have been all that common in general though.

When I had first glance at GCAllocator I observed this as well. I believe GcAlloctor is the better way to camelize it even though druntime has a class GC. It's easier to read for me, consider XMLToHTMLConverter vs. XmlToHtmlConverter or worse XMLHTMLConverter vs. XmlHtmlConverter. See http://stackoverflow.com/questions/1176950/acronyms-in-camel-back

Actually, I find XMLToHTMLConverter to be more legible than XmlToHtmlConverter, because XML and HTML are pretty much always capitalized everywhere else, and so Xml and Html are unfamiliar and jarring. Acronyms are meant to be capitalized. So, the natural thing to do is to put them in all caps in camelcased names. The problem is that you then end up with stuff like XMLTo where the first part of the next word in the name is capitalized but isn't part of the acronym, which is a bit funny. It's completely consistent and legible that way though. There's no confusion over whether the T is part of XML or not. It's just arguably a bit ugly. But _not_ capitalizing acronyms is generally far more hideous IMHO and makes them harder to read, because they're pretty much always capitalized everywhere else. - Jonathan M Davis
Sep 14 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Jonathan M Davis wrote:
 On Wednesday, September 14, 2011 16:12 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Wednesday, September 14, 2011 15:36 dsimcha wrote:
 On 9/14/2011 5:24 PM, Vladimir Panteleev wrote:
 Tiny nitpick: case of "GC" in type/enum names should probably match
 for consistency.

Good point. Do we even have a convention for acronyms in variable/type names? If so is it GcAllocator or GCAllocator?

We haven't been entirely consistent. For instance, we have UtfException, but _every_ other case of utf in the code is either utf (at the beginning of a function) or UTF (I have a pull request which includes fixing the casing on UtfException to match everything else). Given the choice, I'd definitely say that GC should be used and not Gc, and everywhere in Phobos where I've created a function which had an acronym in it, that's what I've done, but without going through the whole code base, I don't know which convention is more common (other than the case of Utf where I did go looking; it's easier when you know what the acronym is rather than looking for _all_ acronyms). I don't think that acronyms have been all that common in general though.

When I had first glance at GCAllocator I observed this as well. I believe GcAlloctor is the better way to camelize it even though druntime has a class GC. It's easier to read for me, consider XMLToHTMLConverter vs. XmlToHtmlConverter or worse XMLHTMLConverter vs. XmlHtmlConverter. See http://stackoverflow.com/questions/1176950/acronyms-in-camel-back

Actually, I find XMLToHTMLConverter to be more legible than XmlToHtmlConverter, because XML and HTML are pretty much always capitalized everywhere else, and so Xml and Html are unfamiliar and jarring. Acronyms are meant to be capitalized. So, the natural thing to do is to put them in all caps in camelcased names. The problem is that you then end up with stuff like XMLTo where the first part of the next word in the name is capitalized but isn't part of the acronym, which is a bit funny. It's completely consistent and legible that way though. There's no confusion over whether the T is part of XML or not. It's just arguably a bit ugly. But _not_ capitalizing acronyms is generally far more hideous IMHO and makes them harder to read, because they're pretty much always capitalized everywhere else.

I think that are capitalized everywhere else because they are separated by spaces in these cases. But how about XMLHTMLConverter? Because I believe you then have to accept this as well without making the rule complicated. Also your argument is only valid for acronyms you know already. What does a DSAFUSLConverter do? I just made this to illustrate the point. Jens
Sep 15 2011
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 15.09.2011, 09:46 Uhr, schrieb Jens Mueller <jens.k.mueller gmx.de>:

 Jonathan M Davis wrote:
 On Wednesday, September 14, 2011 16:12 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Wednesday, September 14, 2011 15:36 dsimcha wrote:
 On 9/14/2011 5:24 PM, Vladimir Panteleev wrote:
 Tiny nitpick: case of "GC" in type/enum names should probably  




 for consistency.

Good point. Do we even have a convention for acronyms in



 names? If so is it GcAllocator or GCAllocator?

We haven't been entirely consistent. For instance, we have


 but _every_ other case of utf in the code is either utf (at the
 beginning of a function) or UTF (I have a pull request which  


 fixing the casing on UtfException to match everything else). Given  


 choice, I'd definitely say that GC should be used and not Gc, and
 everywhere in Phobos where I've created a function which had an  


 in it, that's what I've done, but without going through the whole  


 base, I don't know which convention is more common (other than the  


 of Utf where I did go looking; it's easier when you know what the
 acronym is rather than looking for _all_ acronyms). I don't think  


 acronyms have been all that common in general though.

When I had first glance at GCAllocator I observed this as well. I believe GcAlloctor is the better way to camelize it even though

 has a class GC. It's easier to read for me, consider  

 vs. XmlToHtmlConverter or worse XMLHTMLConverter vs. XmlHtmlConverter.
 See http://stackoverflow.com/questions/1176950/acronyms-in-camel-back

Actually, I find XMLToHTMLConverter to be more legible than XmlToHtmlConverter, because XML and HTML are pretty much always capitalized everywhere else, and so Xml and Html are unfamiliar and jarring. Acronyms are meant to be capitalized. So, the natural thing to do is to put them in all caps in camelcased names. The problem is that you then end up with stuff like XMLTo where the first part of the next word in the name is capitalized but isn't part of the acronym, which is a bit funny. It's completely consistent and legible that way though. There's no confusion over whether the T is part of XML or not. It's just arguably a bit ugly. But _not_ capitalizing acronyms is generally far more hideous IMHO and makes them harder to read, because they're pretty much always capitalized everywhere else.

I think that are capitalized everywhere else because they are separated by spaces in these cases. But how about XMLHTMLConverter? Because I believe you then have to accept this as well without making the rule complicated. Also your argument is only valid for acronyms you know already. What does a DSAFUSLConverter do? I just made this to illustrate the point. Jens

I am fine with camel-cased acronyms. Spaces vs. tabulator anyone?
Sep 15 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, September 15, 2011 09:46:13 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Wednesday, September 14, 2011 16:12 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Wednesday, September 14, 2011 15:36 dsimcha wrote:
 On 9/14/2011 5:24 PM, Vladimir Panteleev wrote:
 Tiny nitpick: case of "GC" in type/enum names should
 probably match for consistency.

Good point. Do we even have a convention for acronyms in variable/type names? If so is it GcAllocator or GCAllocator?

We haven't been entirely consistent. For instance, we have UtfException, but _every_ other case of utf in the code is either utf (at the beginning of a function) or UTF (I have a pull request which includes fixing the casing on UtfException to match everything else). Given the choice, I'd definitely say that GC should be used and not Gc, and everywhere in Phobos where I've created a function which had an acronym in it, that's what I've done, but without going through the whole code base, I don't know which convention is more common (other than the case of Utf where I did go looking; it's easier when you know what the acronym is rather than looking for _all_ acronyms). I don't think that acronyms have been all that common in general though.

When I had first glance at GCAllocator I observed this as well. I believe GcAlloctor is the better way to camelize it even though druntime has a class GC. It's easier to read for me, consider XMLToHTMLConverter vs. XmlToHtmlConverter or worse XMLHTMLConverter vs. XmlHtmlConverter. See http://stackoverflow.com/questions/1176950/acronyms-in-camel-back>

XmlToHtmlConverter, because XML and HTML are pretty much always capitalized everywhere else, and so Xml and Html are unfamiliar and jarring. Acronyms are meant to be capitalized. So, the natural thing to do is to put them in all caps in camelcased names. The problem is that you then end up with stuff like XMLTo where the first part of the next word in the name is capitalized but isn't part of the acronym, which is a bit funny. It's completely consistent and legible that way though. There's no confusion over whether the T is part of XML or not. It's just arguably a bit ugly. But _not_ capitalizing acronyms is generally far more hideous IMHO and makes them harder to read, because they're pretty much always capitalized everywhere else.

I think that are capitalized everywhere else because they are separated by spaces in these cases. But how about XMLHTMLConverter? Because I believe you then have to accept this as well without making the rule complicated. Also your argument is only valid for acronyms you know already. What does a DSAFUSLConverter do? I just made this to illustrate the point.

Part of what you have to do is pick good names. XMLHTMLConverter is a bad name regardless of how you capitalize it. Acronyms are usually capitalized because they stand for something. It's highly abnormal _not_ to capitalize them. Spaces have nothing to do with it. One of the few places that that ever happens is in symbol names in some programs, because the programmers involved thought that it was ugly to have that many capital letters in a row. Outside of programming, not capitalizing them is rare, and inside of programming, it depends on who's writing the code. Personally, I do _not_ like it when acronyms have mixed capitalization, and I think that symbol names with fully capitalized acronyms are just fine. You just need to be smart about what you name your symbols - which you should be doing anyway. - Jonathan M Davis
Sep 15 2011
prev sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Jonathan M Davis wrote:
 On Thursday, September 15, 2011 09:46:13 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Wednesday, September 14, 2011 16:12 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Wednesday, September 14, 2011 15:36 dsimcha wrote:
 On 9/14/2011 5:24 PM, Vladimir Panteleev wrote:
 Tiny nitpick: case of "GC" in type/enum names should
 probably match for consistency.

Good point. Do we even have a convention for acronyms in variable/type names? If so is it GcAllocator or GCAllocator?

We haven't been entirely consistent. For instance, we have UtfException, but _every_ other case of utf in the code is either utf (at the beginning of a function) or UTF (I have a pull request which includes fixing the casing on UtfException to match everything else). Given the choice, I'd definitely say that GC should be used and not Gc, and everywhere in Phobos where I've created a function which had an acronym in it, that's what I've done, but without going through the whole code base, I don't know which convention is more common (other than the case of Utf where I did go looking; it's easier when you know what the acronym is rather than looking for _all_ acronyms). I don't think that acronyms have been all that common in general though.

When I had first glance at GCAllocator I observed this as well. I believe GcAlloctor is the better way to camelize it even though druntime has a class GC. It's easier to read for me, consider XMLToHTMLConverter vs. XmlToHtmlConverter or worse XMLHTMLConverter vs. XmlHtmlConverter. See http://stackoverflow.com/questions/1176950/acronyms-in-camel-back>

XmlToHtmlConverter, because XML and HTML are pretty much always capitalized everywhere else, and so Xml and Html are unfamiliar and jarring. Acronyms are meant to be capitalized. So, the natural thing to do is to put them in all caps in camelcased names. The problem is that you then end up with stuff like XMLTo where the first part of the next word in the name is capitalized but isn't part of the acronym, which is a bit funny. It's completely consistent and legible that way though. There's no confusion over whether the T is part of XML or not. It's just arguably a bit ugly. But _not_ capitalizing acronyms is generally far more hideous IMHO and makes them harder to read, because they're pretty much always capitalized everywhere else.

I think that are capitalized everywhere else because they are separated by spaces in these cases. But how about XMLHTMLConverter? Because I believe you then have to accept this as well without making the rule complicated. Also your argument is only valid for acronyms you know already. What does a DSAFUSLConverter do? I just made this to illustrate the point.

Part of what you have to do is pick good names. XMLHTMLConverter is a bad name regardless of how you capitalize it. Acronyms are usually capitalized because they stand for something. It's highly abnormal _not_ to capitalize them. Spaces have nothing to do with it. One of the few places that that ever happens is in symbol names in some programs, because the programmers involved thought that it was ugly to have that many capital letters in a row. Outside of programming, not capitalizing them is rare, and inside of programming, it depends on who's writing the code. Personally, I do _not_ like it when acronyms have mixed capitalization, and I think that symbol names with fully capitalized acronyms are just fine. You just need to be smart about what you name your symbols - which you should be doing anyway.

Either way it'll be nice to have this fixed in the style guide. Even though I prefer the Java/.NET convention for acronyms. Maybe we can just decide this and move on. Jens
Sep 15 2011
parent Kagamin <spam here.lot> writes:
Jens Mueller Wrote:

 Either way it'll be nice to have this fixed in the style guide. Even
 though I prefer the Java/.NET convention for acronyms. Maybe we can just
 decide this and move on.

It also can be difficult to write short words with mixed case, so two-char words like GC, IS, AS, TO, ON, MS, OF, IO should have uniform casing to ease typing, though three-char words are not so short to require uniform casing and can be easily typed with mixed case.
Sep 15 2011