
<html><body><div>On Oct 05, 2012, at 06:13 AM, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:<br><br><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"> I'm of the opinion that a module is a collection of very similar<br> functionality, typically things that you would use together in the<br> same code - I think the core.sync package fits that criteria pretty<br> well (for instance, you can rarely use a condition variable without a<br> mutex).<br> </div></div></blockquote><span> </span><br>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.<br><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"> I'm not quite sure what your point is about "as large abstractions as possible"?<br> </div></div></blockquote><span> </span><br>A lot of people seems to have a habit of writing large modules, classes and methods. Phobos is a perfect example of this.<br><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"> I think the comparison is way exaggerated. std.datetime is 30k+ lines<br> while the core.sync package totals 2.2k lines. I know what you're<br> saying, I'm just not sure it really applies here.</div></div></blockquote><span> </span><br>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.<br><br>--<br>/Jacob Carlborg<br></div></div></body></html>