std.allocator: nomenclature needed

[Leandro Motta Barros via Digitalmars-d]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150515/1a828c41/attachment.html>