Phobos addition formal review: std.experimental.allocator

[Andrei Alexandrescu via Digitalmars-d]

On 6/23/15 6:11 PM, Mike wrote:
> It seems there is already precedent with std.digest.digest
> (http://dlang.org/phobos/std_digest_digest.html).  I'm sorry I wasn't
> aware of this at the time.  std.allocator.porcelain couldn't stand, and
> I suggested what seemed most natural to me. I've spend a number of years
> in C#-land, and that of course has an affect on my biases.  But D is not
> C# (thankfully).

Well it's about time we engineers stop suspending our sense of 
ridiculousness when looking at programmer names. Once some minimal sense 
and sensibility is in action, it's clear that something like 
std.digest.digest.digest is just ridiculous. That shouldn't have passed 
review, and today it shouldn't be used as a precedent.

> Following the std.digest.digest precedent, there should probably be
> std.allocator.allocator.  It stinks IMO (std.digiest.api and
> std.allocator.api would have been much better), but the naming
> discussions are starting to take their toll.

std.allocator.allocator.IAllocator std.allocator.allocator.theAllocator;

Yep, "ridiculous" is the first thing that comes to mind.

I find it difficult to digest (ehm) the fact that the same community 
that thinks "std.allocator" is just not going to cut the mustard, 
simultaneously believes "std.allocator.allocator" is a good idea.

> Anyway, I suggest std.allocator.allocator as a compromise and a
> precedent to follow in the future.  It's tolerable.
>
> Also, I can't seem to navigate std.allocator tree in the left nav at
> http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html.
> Please advise or fix.

Yah, noticed that too. Will look into it tomorrow.


Andrei