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
