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.


 I think Default(Templated)AllocatorFunctions are better
 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 reply 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.


 I think Default(Templated)AllocatorFunctions are better
 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.


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
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,  




 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.


 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.


 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 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 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


 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?


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 reply "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


 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?


 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
parent reply 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
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 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 reply 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
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  








 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


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> 


 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.


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> 


 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.


 
 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