On 08/01/2010 09:32 AM, Philippe Sigaud wrote:
On Sun, Aug 1, 2010 at 16:02, dsimcha <[email protected] <mailto:[email protected]>> wrote:[flat / nested] Please, no. This is why I hate Tango and Java. It's too hard to find what you need, and you have to write too much import declaration boilerplate. I agree that Java pushed that too far for my taste also. Looking at Tango, it's indeed really nested. But hey, std.c.* is already two-levels and I never heard anyone complaining. I thought there was a kind of agreement about some modules in Phobos that were beginning to be quite big, but I may be wrong. Now that I think about it, my real problem on this point is not so much that std.algorithm is too big but that: - I don't always know whether such or such function in in std.string, std.algorithm, std.range, etc. - The doc pages are not particularly organized. I have to use Adam Ruppe's "find D keyword" website (very handy) regularly... I love Phobos's flat, simple, even if at times sloppy, import system. Even so, I have a module in my personal lib that just publicly imports the 10 or so Phobos modules I use most frequently, because even in Phobos the amount of import declaration boilerplate is too much, but using std.all caused too many naming collisions with modules that I don't use. I do the same. I always end up importing the same 10-15 modules. But, what about putting all() and some() in std.algorithm?
I agree that all of the functions you suggested deserve a place in std.algorithm (or std.range). Please add one bugzilla entry or better yet let me know if you'd like to join Phobos's devs (subject to team approval) so you can add them yourself.
Also, I agree that std.algorithm has gotten a bit large. Any sensible ideas for addressing that should be discussed. Off the top of my head, I'm thinking that mutators vs. non-mutators could be a possible criterion for separation.
BTW, it warms my heart to see that our std.algorithm is the fourth Google hit when searching for std::algorithm (or std.algorithm, which seems to produce the same results). I feel std.container can be a similarly compelling offering. *cough*RBTree*cough*Steve*cough*
Andrei
