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