What functions could be added to std.algorithm?
Philippe Sigaud
philippe.sigaud at gmail.com
Sun Aug 1 07:32:50 PDT 2010
On Sun, Aug 1, 2010 at 16:02, dsimcha <dsimcha at yahoo.com> 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?
Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20100801/564ce7ea/attachment.html>
More information about the Digitalmars-d
mailing list