Hi folks,

I've been thinking that it might be a good idea to merge the entire core.sync package into one module for a couple of reasons:

1) The modules are small.
1.a) I don't think they really need an entire package and several
files to be navigable (at least to me, it makes it more annoying to go
through them).
1.b) The idea seems to be class-per-module which is quite unusual in
typical D code.
2) It'll be easier for the user to just import one module, instead of
several depending on what synchronization primitives they need.
3) It's consistent with the general interface in core.* (the only
nested modules/packages we have are in core.sys and core.stdc).

Thoughts?

Regards,
Alex
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 4 okt 2012, at 12:48, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> Hi folks,
> 
> I've been thinking that it might be a good idea to merge the entire core.sync package into one module for a couple of reasons:
> 
> 1) The modules are small.
> 1.a) I don't think they really need an entire package and several
> files to be navigable (at least to me, it makes it more annoying to go
> through them).
> 1.b) The idea seems to be class-per-module which is quite unusual in
> typical D code.
> 2) It'll be easier for the user to just import one module, instead of
> several depending on what synchronization primitives they need.
> 3) It's consistent with the general interface in core.* (the only
> nested modules/packages we have are in core.sys and core.stdc).
> 
> Thoughts?


I think this is a terrible idea. In general in D we need to start dividing existing modules in to smaller ones, not the opposite. Just look at the mess that Phobos is, especially std.datetime with its over 30k lines of code. I think that the modules in core.sync have a good size. A few short ones and a few longer ones. Just because Phobos choose to put a whole package in one single module doesn't mean it's a good idea. People seems to have an obsession of writing as large abstractions (modules, classes, methods) as possible. That's just bad style and should not be encouraged.

Just my thoughts.

-- 
/Jacob Carlborg

_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Thu, Oct 4, 2012 at 8:27 PM, Jacob Carlborg <doob@me.com> wrote:
>
> On 4 okt 2012, at 12:48, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
>
>> Hi folks,
>>
>> I've been thinking that it might be a good idea to merge the entire core.sync package into one module for a couple of reasons:
>>
>> 1) The modules are small.
>> 1.a) I don't think they really need an entire package and several
>> files to be navigable (at least to me, it makes it more annoying to go
>> through them).
>> 1.b) The idea seems to be class-per-module which is quite unusual in
>> typical D code.
>> 2) It'll be easier for the user to just import one module, instead of
>> several depending on what synchronization primitives they need.
>> 3) It's consistent with the general interface in core.* (the only
>> nested modules/packages we have are in core.sys and core.stdc).
>>
>> Thoughts?
>
>
> I think this is a terrible idea. In general in D we need to start dividing existing modules in to smaller ones, not the opposite. Just look at the mess that Phobos is, especially std.datetime with its over 30k lines of code. I think that the modules in core.sync have a good size. A few short ones and a few longer ones. Just because Phobos choose to put a whole package in one single module doesn't mean it's a good idea. People seems to have an obsession of writing as large abstractions (modules, classes, methods) as possible. That's just bad style and should not be encouraged.
>
> Just my thoughts.

I'm of the opinion that a module is a collection of very similar functionality, typically things that you would use together in the same code - I think the core.sync package fits that criteria pretty well (for instance, you can rarely use a condition variable without a mutex).

I'm not quite sure what your point is about "as large abstractions as possible"?

I think the comparison is way exaggerated. std.datetime is 30k+ lines while the core.sync package totals 2.2k lines. I know what you're saying, I'm just not sure it really applies here.

Regards,
Alex
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Oct 05, 2012, at 06:13 AM, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:

> I'm of the opinion that a module is a collection of very similar functionality, typically things that you would use together in the same code - I think the core.sync package fits that criteria pretty well (for instance, you can rarely use a condition variable without a mutex).

Then just add a module "core.sync.all" that imports all modules in that package. Again we need compiler support for "import pack.*" to import all modules of a package. We do have this module system for a reason and it's pretty flexible.

> I'm not quite sure what your point is about "as large abstractions as possible"?

A lot of people seems to have a habit of writing large modules, classes and methods. Phobos is a perfect example of this.

> I think the comparison is way exaggerated. std.datetime is 30k+ lines while the core.sync package totals 2.2k lines. I know what you're saying, I'm just not sure it really applies here.

I don't think we need to divide the modules in core.sync, they have a good size, it was more how I see it in general. BTW, creating a single module of the core.sync package will just break code for, in my opinion, a very bad reason.

--
/Jacob Carlborg