Am 02.09.2011, 14:54 Uhr, schrieb Robert Jacques <[email protected]>:
On Thu, 01 Sep 2011 14:58:07 -0400, David Nadlinger <[email protected]>
wrote:
On 9/1/11 8:45 PM, Don wrote:
While on this bikeshedding issue -- the name 'regionallocator' is
horribly long for such an important object. I think if it stays with a
long-winded name, it won't be used as frequently as it deserves.
I guess std.alloc.region.RegionAlloc is about the shortest viable symbol
name before it gets too confusing.
David
Given names like Malloc, REalloc, allocA, Calloc and Qalloc, what's
wrong with either ralloc, allocr or some other letter + alloc
combination?
As a Java user, I agree with Lars on the naming. This is convenient for
the user:
atd.allocator.GcAllocator
std.allocator.BikeshedAllocator
std.allocator.RegionAllocator
But it will make std/allocator.d grow, maybe to big. (In Java these would
still be three files.)
So David's proposal looks like the best compromise to me.
std.alloc[ator[s]].region.R[egion]Alloc[ator] :)
Since we already have a lot of std modules and I'm sometimes overwhelmed
when I look for something on the D home page, I would prefer a speaking
name for the top level at least. So allocator[s] instead of alloc (which
misleads me to think of low-level C API functionality). YMMV.
