On 6/23/15 2:14 PM, Tofu Ninja wrote:
> On Tuesday, 23 June 2015 at 21:12:10 UTC, Dicebot wrote:
>> So you have chosen worst of both worlds - neither give power users
>> ability to fine tune imports nor allow casual users always go with
>> `import std.allocator` and be happy? :)
>>
>> If anything, that will be the first package.d in Phobos (AFAIK) which
>> won't feature public import of _all_ package modules.
>
> I agree, a minimalist package.d seems utterly pointless to me.

It's not minimalist. -- Andrei

On 6/23/15 2:29 PM, Dmitry Olshansky wrote:
> I'm not sure if that's the case with std.allocator but importing package
> IMHO should import _typical_ set of submodules.
>
> Things that are more niche and rare (power user oriented) shouldn't
> really be in package.d

Yah, that attitude describes std.allocator well. -- Andrei

On Tuesday, 23 June 2015 at 19:16:33 UTC, Andrei Alexandrescu wrote:
>
> The case with std.allocator is not everything is imported in it, so no bloating no nothing. -- Andrei

My assumption with D libraries is that "import std.thing;" imports everything in the the whole package.


Not that I've a strong opinion on it either.

On 6/23/15 6:07 PM, Andrei Alexandrescu wrote:
> On 6/23/15 2:12 PM, Dicebot wrote:
>> So you have chosen worst of both worlds - neither give power users
>> ability to fine tune imports nor allow casual users always go with
>> `import std.allocator` and be happy? :)
>
> There is functionality in std.allocator to get anyone started who
> doesn't want to sit down and define their own allocator.
>
> People who want to do that can import std.allocator.building_blocks
> which is a package fully including all that's needed.
>
>> If anything, that will be the first package.d in Phobos (AFAIK) which
>> won't feature public import of _all_ package modules.
>
> I'm not afraid of creating precedent if that's the best way to go.
> Again: I have the impression we're blocked into an assumption we didn't
> take critically until now.

What happened basically was:

1. There's too much crap in some modules, it's hard to maintain, hard to process.
2. Let's split it up! Oh, but some people want to be able to import everything a la java's import java.io.*, and existing code!!!
3. package.d is the solution, just import that and it's the same thing!

I personally think that if we want to define package.d as "importing all the submodules", then we should stick to that. If we want to go another direction, we need to redo all the other splitting of modules we have done so far, as that is the pattern.

I'd recommend std.allocator.basic instead of std.allocator for a basic direction. If it doesn't make sense to import ALL of std.allocator ever, then drop package.d.

But you don't have to listen to me :)

-Steve

On 6/23/15 3:17 PM, Steven Schveighoffer wrote:
> we need to redo

no

On 6/23/15 6:18 PM, Andrei Alexandrescu wrote:
> On 6/23/15 3:17 PM, Steven Schveighoffer wrote:
>> we need to redo
>
> no

Yeah, so then it becomes import std.somepackage means import all the modules in that package, except for std.allocator. But that's fine, if we want that type of inconsistency, we can just RTFM the newbies.

-Steve

Ok, if you feel so strongly about it, let's not waste time in arguing. You are not obliged to agree to any of reviewer comments so as long as everyone is clear about their opinion, the eventual voting will decide. I am simply pointing out things that catch my attention.

On Tuesday, 23 June 2015 at 21:12:10 UTC, Dicebot wrote:
> On Tuesday, 23 June 2015 at 19:17:21 UTC, Andrei Alexandrescu

>>
>> The "import std.allocator" is already minimal - only contains the high level stuff. -- Andrei
>
> So you have chosen worst of both worlds - neither give power users ability to fine tune imports nor allow casual users always go with `import std.allocator` and be happy? :)
>
> If anything, that will be the first package.d in Phobos (AFAIK) which won't feature public import of _all_ package modules.

Well, since it was apparently my lousy suggestion that led to this, I guess I'm obligated to comment.

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).

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.

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.

Mike

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

On Wednesday, 24 June 2015 at 04:00:11 UTC, Andrei Alexandrescu wrote:
>
> 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.

Of course you are right. It was indeed a poor suggestion.  But it's the only example I could find where a separate module name was used to declare the high-level API.  Perhaps it was even written before package.d existed.

The case against std.allocator isn't about the name, but about the fact that it doesn't do what people, apparently, expect: import the entire public API.

I count only 4 uses of package.d in official Phobos:
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/package.d
https://github.com/D-Programming-Language/phobos/blob/master/std/container/package.d
https://github.com/D-Programming-Language/phobos/blob/master/std/range/package.d
https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d

All of them seem to import the entire public API, but only std.algorithm.package.d is exclusively used for public imports.  The others all have some definition of high-level API features.  So, I don't see a precedent one way or another.  And maybe that's how it should be:  defined based on the intended use of the package.

Unfortunately, those against using package.d for the high-level API, did not seem to offer a suggestion for where to put your porcelain.  So, if you wish to accommodate them and need a name, consider std.allocator.api.

Mike