[D-runtime] Merge core.sync package into a single module?

[Alex Rønne Petersen]

On Thu, Oct 4, 2012 at 8:27 PM, Jacob Carlborg <doob at me.com> wrote:
>
> On 4 okt 2012, at 12:48, Alex Rønne Petersen <xtzgzorex at 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