On Saturday 09 October 2010 03:46:42 Denis wrote: > This is an interesting discussion that I personally find very important. > > One of the most annoying things in Phobos is that modules are too > large and by too large I mean they contain lots and lots of stuff that > are loosely related to each other. > > I'm strongly against design like that. As a programmer I've been grown > with idea of module separation in mind. At work, we are spending tens > of hours discussing the same problem: code dependency reduction. In > Phobos, it's just a disaster - every module is a monster that heavily > depends or other monsters alike. > > I've heard an opinion that it's hard for people to remember too many > modules names. However, they know that you need to import std.array to > use Appender, or std.algorithm to use sort etc. As such, it shouldn't > be any harder for them to import std.algorithm.sort; or import > std.array.appender; Alternatively, they may import std.algorithm.all > and have the whole bulk of features at their disposal, but from my > experience, that's not what is needed anyway. Here is a random import > snippet from my code: > > import core.memory : GC; > import core.atomic : cas; > import core.stdc.string : memcpy; > import core.sync.semaphore : Semaphore; > > In ddmd, I have > > module dmd.expression.Add; > module dmd.expression.And; > module dmd.expression.ArrayLength; > etc > > each declaring just *one* method and only imports stuff that that > particular module needs. It helps reducing module dependencies *a > lot*.
I, on the other hand, think that it's horrible to be importing functions or types individually. I'd sooner want to import the entirety of Phobos than import an individual function. Now, you don't want modules to get too large to be sure, but I'm not aware of a single module at this point that I'd consider too large. std.container may get that way once it has a full complement of containers, but none are currently what I'd consider too big. My datetime code is pushing it as a single module, but I don't think that it's really a problem that way except that the file itself gets quite large. Certainly, it's far easier to know that an algorithm is likely to be in std.algorithm than to have a host of different modules with different types of algorithms in them and have to figure out what is where. Obviously some stuff splits out fairly nicely (like string and range being their own modules), but taking something like the Java approach and essentially having a class per module would create _way_ too many modules. I think that, for the most part, the current module scheme in Phobos is pretty good. I expect that we'll have to breakdown at some point and introduce a multi-level hierarchy for at least some modules rather than have the module hierarchy be entirely flat, but for the most part, what we have is good. What we lack is functionality, not good module layout. And really, if for some reason which I can't comprehend, you actually _want_ to import functions individually (like you and various other folks out there seem to like to), you can still do that. And as soon as you're importing them individually, they could each be in their own module for all it matters with regards to importing (though obviously that would be bad for the documentation). So, I'd say that it's generally better to have modules that are on the large side rather than on the small side. - Jonathan M Davis _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
