https://github.com/D-Programming-Language/phobos/pull/2845

I'm getting quite happy with it.
I think it's a good and fairly minimal but useful starting point.

It'd be great to get some reviews from here.

Just a quick concern, I don't think a package.d should ever have anything except imports in it. Put all the actual aliases and color lists in some other submodule that can be imported independently with minimal dependencies.

On Tuesday, 23 June 2015 at 15:01:59 UTC, Adam D. Ruppe wrote:
> Just a quick concern, I don't think a package.d should ever have anything except imports in it. Put all the actual aliases and color lists in some other submodule that can be imported independently with minimal dependencies.

std/range/package.d and std/regex/package.d both have a bunch of stuff in. Why not?

On Tuesday, 23 June 2015 at 15:24:44 UTC, John Colvin wrote:
> std/range/package.d and std/regex/package.d both have a bunch of stuff in. Why not?

Those are also mistakes (well, probably just semi-migrated from the old big module). Suppose you want some of that stuff without the rest of the package. How do you get to it?

The biggest benefit of breaking up the big modules is so you can access some of it without requiring all of it. But when the part you want is in the package.d, you can't get it independently anymore; importing that also imports everything else, negating the reason it was split up in the first place.

On 23-Jun-2015 18:24, John Colvin wrote:
> On Tuesday, 23 June 2015 at 15:01:59 UTC, Adam D. Ruppe wrote:
>> Just a quick concern, I don't think a package.d should ever have
>> anything except imports in it. Put all the actual aliases and color
>> lists in some other submodule that can be imported independently with
>> minimal dependencies.
>
> std/range/package.d and std/regex/package.d both have a bunch of stuff
> in. Why not?

Speaking of regex - it's temporary situation. The idea is to both expose more submodules and keep less cruft in package.d.

I'm not for public imports only but for minimizing the amount of code in package.d

-- 
Dmitry Olshansky

On 24/06/2015 3:29 a.m., Adam D. Ruppe wrote:
> On Tuesday, 23 June 2015 at 15:24:44 UTC, John Colvin wrote:
>> std/range/package.d and std/regex/package.d both have a bunch of stuff
>> in. Why not?
>
> Those are also mistakes (well, probably just semi-migrated from the old
> big module). Suppose you want some of that stuff without the rest of the
> package. How do you get to it?

I use a file called defs for this. Works brilliantly.

On Tuesday, 23 June 2015 at 15:29:42 UTC, Adam D. Ruppe wrote:
> On Tuesday, 23 June 2015 at 15:24:44 UTC, John Colvin wrote:
>> std/range/package.d and std/regex/package.d both have a bunch of stuff in. Why not?
>
> Those are also mistakes (well, probably just semi-migrated from the old big module). Suppose you want some of that stuff without the rest of the package. How do you get to it?
>
> The biggest benefit of breaking up the big modules is so you can access some of it without requiring all of it. But when the part you want is in the package.d, you can't get it independently anymore; importing that also imports everything else, negating the reason it was split up in the first place.

But that's more an argument against putting anything _except_ the basic definitions into package.d, no? Then you can always exclude the more specific stuff whenever you need it, and those modules themselves can publicly import package.d.

On Tuesday, 23 June 2015 at 16:14:59 UTC, Marc Schütz wrote:
> But that's more an argument against putting anything _except_ the basic definitions into package.d, no? Then you can always exclude the more specific stuff whenever you need it, and those modules themselves can publicly import package.d.

What if you want the basic definitions alone to build something off of?

If I want to write an image library that can share pixels with your image library, I might import std.color just to get the pixel format. I don't need the list of colors nor any algorithms, I just want to share the basic type so our two libraries can pass data back and forth.

So I write like

RGBA8[] readImage() {}

With the std.color functions, some other library can now take that pixel array and convert it or whatever they need to do. Great, you can use my thing pretty easily.

But I don't need any conversions myself. I don't do transformations. I don't use named colors, blending functions, or anything else. (Maybe my image format is extremely simple.)


So pulling the rest of the library would waste compile time and binary space. Especially if a user wanted my extremely simple image format exactly because they were short on time and space.



So ideally, my module would ONLY import std.color.basic_types or something like that.... but alas, RGBA8 is defined in package.d, so if I want it, whether I like it or not, I just pulled half the std.color library....

which just pulled std.traits and std.typecons, which, thankfully, didn't import anything else, but that's not the case for so many Phobos modules.



This layout isn't bad today, the std.color in the PR is pretty small and pretty lazy thanks to the templates and local imports in them, but I still want to set a precedent in Phobos of untangling the web of dependencies by moving as much independent code as reasonably possible to independent modules.

On Tue, Jun 23, 2015 at 03:24:41PM +0000, John Colvin via Digitalmars-d wrote:
> On Tuesday, 23 June 2015 at 15:01:59 UTC, Adam D. Ruppe wrote:
> >Just a quick concern, I don't think a package.d should ever have anything except imports in it. Put all the actual aliases and color lists in some other submodule that can be imported independently with minimal dependencies.
> 
> std/range/package.d and std/regex/package.d both have a bunch of stuff in.  Why not?

That's a temporary situation. When those packages were broken up, we didn't want to make too extensive a change, so we left the less important bits in package.d. Ideally, however, they should be moved into their own subpackages.


T

-- 
EMACS = Extremely Massive And Cumbersome System

On Tuesday, 23 June 2015 at 17:11:57 UTC, Adam D. Ruppe wrote:
> On Tuesday, 23 June 2015 at 16:14:59 UTC, Marc Schütz wrote:
>> But that's more an argument against putting anything _except_ the basic definitions into package.d, no? Then you can always exclude the more specific stuff whenever you need it, and those modules themselves can publicly import package.d.
>
> What if you want the basic definitions alone to build something off of?
>
> If I want to write an image library that can share pixels with your image library, I might import std.color just to get the pixel format. I don't need the list of colors nor any algorithms, I just want to share the basic type so our two libraries can pass data back and forth.
>
> So I write like
>
> RGBA8[] readImage() {}
>
> With the std.color functions, some other library can now take that pixel array and convert it or whatever they need to do. Great, you can use my thing pretty easily.
>
> But I don't need any conversions myself. I don't do transformations. I don't use named colors, blending functions, or anything else. (Maybe my image format is extremely simple.)
>
>
> So pulling the rest of the library would waste compile time and binary space. Especially if a user wanted my extremely simple image format exactly because they were short on time and space.
>
>
>
> So ideally, my module would ONLY import std.color.basic_types or something like that.... but alas, RGBA8 is defined in package.d, so if I want it, whether I like it or not, I just pulled half the std.color library....
>
> which just pulled std.traits and std.typecons, which, thankfully, didn't import anything else, but that's not the case for so many Phobos modules.
>
>
>
> This layout isn't bad today, the std.color in the PR is pretty small and pretty lazy thanks to the templates and local imports in them, but I still want to set a precedent in Phobos of untangling the web of dependencies by moving as much independent code as reasonably possible to independent modules.

Isn't this what selective imports are for? Admittedly it's not quite as convenient, but it does let you choose exactly what you want. You can even make a module that wraps a manually selected set of imports, e.g. you do your own basic_types module.

In the end, if you have specific requirements, you have to be specific.