www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.allocator: nomenclature needed

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ready for yet another name debate? Here's an opportunity!

I just added:

http://erdani.com/d/phobos-prerelease/std_experimental_allocator_auto_deallocator.html

https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/auto_deallocator.d

It's very useful, but it seems the name doesn't do it justice.

Also, I need two more good names: one for what's now called "porcelain" 
- high-level typed interface for allocators, and one for "best of 
Beatles" (not defined yet) - a module collecting a number of canned good 
allocator designs by connecting together components.


Thanks,

Andrei
May 14 2015
next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Friday, 15 May 2015 at 03:27:15 UTC, Andrei Alexandrescu wrote:
 Ready for yet another name debate? Here's an opportunity!

 I just added:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_auto_deallocator.html

 https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/auto_deallocator.d
BulkDeallocator FlushDeallocator
 Also, I need two more good names: one for what's now called 
 "porcelain" - high-level typed interface for allocators, and 
 one for "best of Beatles" (not defined yet) - a module 
 collecting a number of canned good allocator designs by 
 connecting together components.
std.allocator.bestof std.allocator.recipes std.allocator.cots std.allocator.premade std.allocator.prefab
 Thanks,

 Andrei
May 15 2015
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 15 May 2015 at 07:03:12 UTC, ponce wrote:
 std.allocator.prefab
I like this. If we consider the purpose of the module to provide vetted, generally useful allocator compositions, then I think this kind of name makes sense. A very different name might be possible but it probably requires expressing the purpose of the module differently.
May 16 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-05-15 05:27, Andrei Alexandrescu wrote:
 Ready for yet another name debate? Here's an opportunity!

 I just added:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_auto_deallocator.html


 https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/auto_deallocator.d


 It's very useful, but it seems the name doesn't do it justice.
ScopedAllocator? -- /Jacob Carlborg
May 15 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/15/15 2:33 AM, Jacob Carlborg wrote:
 On 2015-05-15 05:27, Andrei Alexandrescu wrote:
 Ready for yet another name debate? Here's an opportunity!

 I just added:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_auto_deallocator.html



 https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/auto_deallocator.d



 It's very useful, but it seems the name doesn't do it justice.
ScopedAllocator?
We have a winner. Thanks! https://github.com/andralex/phobos/commit/e6e11db13c2d224bdb600d944642473f35d10f77 Andrei
May 15 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-05-15 19:16, Andrei Alexandrescu wrote:

 We have a winner. Thanks!
 https://github.com/andralex/phobos/commit/e6e11db13c2d224bdb600d944642473f35d10f77
BTW, I see that many of your filenames have words separated with underscores. We're not using that standard anywhere else, as far as I know. Although I'm not against it, I rather prefer it if pascal casing cannot be used. -- /Jacob Carlborg
May 16 2015
next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Saturday, 16 May 2015 at 09:11:57 UTC, Jacob Carlborg wrote:
 On 2015-05-15 19:16, Andrei Alexandrescu wrote:

 We have a winner. Thanks!
 https://github.com/andralex/phobos/commit/e6e11db13c2d224bdb600d944642473f35d10f77
BTW, I see that many of your filenames have words separated with underscores. We're not using that standard anywhere else, as far as I know. Although I'm not against it, I rather prefer it if pascal casing cannot be used.
http://dlang.org/dstyle.html Check the "Moudles" section. According to Github[1] this has been the standard since 2012. [1] https://github.com/D-Programming-Language/dlang.org/commit/6eaf0046df6e02d5b00d333035afbd9e41295e93
May 16 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/16/15 2:11 AM, Jacob Carlborg wrote:
 On 2015-05-15 19:16, Andrei Alexandrescu wrote:

 We have a winner. Thanks!
 https://github.com/andralex/phobos/commit/e6e11db13c2d224bdb600d944642473f35d10f77
BTW, I see that many of your filenames have words separated with underscores. We're not using that standard anywhere else, as far as I know. Although I'm not against it, I rather prefer it if pascal casing cannot be used.
I thought that was the recommended style for Phobos. -- Andrei
May 16 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-05-16 18:34, Andrei Alexandrescu wrote:

 I thought that was the recommended style for Phobos. -- Andrei
I don't know. There's not a single public module with an underscore in its name. If that's the recommended style that I suggest we start encouraging/enforcing that. Like std.experimental.logger, it has several modules that should have an underscore. -- /Jacob Carlborg
May 16 2015
prev sibling next sibling parent reply Leandro Motta Barros via Digitalmars-d <digitalmars-d puremagic.com> writes:
Not a naming suggestion, but a suggestion for a guideline on how to chose
names: make it simpler for most users.

If we still want one million users:

1. Most of them will never bother with std.allocator (by which I don't mean
it is not necessary!)
2. Of those relatively few using std.allocator, most will use the canned,
easy-to-use, high-level stuff
3. Just a few users will reach the plumbing.

As someone personally prefering to remain in group 1 forever, but I willing
to visit group 2 occasionally if necessary, I'd prefer to simply say

import std.allocator;

and get access to the higher-level stuff instead of

import std.allocator.whatever;

This has implications even for the hypothetical day in which I'll be
required to use std.allocator. The closer to the root I find the stuff I
need (that is, the high-level stuff), the quicker I'll find it. If I find
lower-level stuff before finding the higher-level ones, I might even be
fooled to believe that I don't have better (better for me) alternatives,
and start a path of unnecessary suffering.

The bottom line: please make the naming reflect the expected usage, taking
into account the mythical one million users. Simpler names for the stuff
that will be used by most of us.

Cheers,

LMB









On Fri, May 15, 2015 at 12:27 AM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 Ready for yet another name debate? Here's an opportunity!

 I just added:


 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_auto_deallocator.html


 https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/auto_deallocator.d

 It's very useful, but it seems the name doesn't do it justice.

 Also, I need two more good names: one for what's now called "porcelain" -
 high-level typed interface for allocators, and one for "best of Beatles"
 (not defined yet) - a module collecting a number of canned good allocator
 designs by connecting together components.


 Thanks,

 Andrei
May 15 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/15/15 6:26 AM, Leandro Motta Barros via Digitalmars-d wrote:
 Not a naming suggestion, but a suggestion for a guideline on how to
 chose names: make it simpler for most users.
[snip] Sensible argument. Yes, importing std.allocator will make the high-level goodies available. (Not sure whether it should /also/ make the low-level stuff available, too.) -- Andrei
May 15 2015
prev sibling next sibling parent Etienne Cimon <etcimon gmail.com> writes:
On 2015-05-14 23:27, Andrei Alexandrescu wrote:
 Also, I need two more good names: one for what's now called "porcelain"
 - high-level typed interface for allocators, and one for "best of
 Beatles" (not defined yet) - a module collecting a number of canned good
 allocator designs by connecting together components.
This may sound like a request, but it's probably more of a direction. I intended to start writing my D software on top of a ScopedPool stack. I'll explain... It's a manual memory management strategy I devised (invented) because I needed to optimize heavy use of XML/Json/DOM/tree-based structures. The idea is to allocate in the top-most pool of the caller and de-allocate when the pool goes out of scope. A pool is nice because it's meant to trash all the objects instantly, it's much faster and efficient. Just like when a process crashes. You simply use `alloc!T` instead of `new T`. The scope is created with `auto pool = ScopedPool(1024*16);`, which basically allocates pools in 16kb increments. You can use `pool.freeze()` and then it will temporarily pop the pool from the stack so that `alloc!T` uses the pool one level lower. The lowest level is the GC. Example: https://github.com/etcimon/spd Implementation source: https://github.com/etcimon/memutils/blob/master/source/memutils/scoped.d If you like the idea, let this be a permission to license it to Boost =)
May 16 2015
prev sibling parent reply "Mike" <none none.com> writes:
On Friday, 15 May 2015 at 03:27:15 UTC, Andrei Alexandrescu wrote:

 Also, I need two more good names: one for what's now called 
 "porcelain" - high-level typed interface for allocators
Would it be better to move the porcelain code into package.d so the nomenclature simply becomes `import std.allocator;`? Mike
May 18 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/18/15 7:21 PM, Mike wrote:
 On Friday, 15 May 2015 at 03:27:15 UTC, Andrei Alexandrescu wrote:

 Also, I need two more good names: one for what's now called
 "porcelain" - high-level typed interface for allocators
Would it be better to move the porcelain code into package.d so the nomenclature simply becomes `import std.allocator;`?
Probably a good thing to do. -- Andrei
May 18 2015
parent "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 19 May 2015 at 05:17:14 UTC, Andrei Alexandrescu 
wrote:
 Would it be better to move the porcelain code into package.d 
 so the
 nomenclature simply becomes `import std.allocator;`?
Probably a good thing to do. -- Andrei
I've been thinking about this as well and couldn't think of a better name either. For what it's worth I agree with placing them in std.allocator.
May 18 2015