Dave Rolsky writes: > The slowness and amount of code are not nearly as important as the > fact that the API is inelegant.
I completely agree with that -- far better for your internals to be a bit wonky than for every user of your module to have to jump through hoops. Also, there's always the possibility that a more elegant algorithm or something can be found that will make it faster or use less code later -- but changing the API later creates real problems. > This was a big concern of mine with the DateTime code. I _hope_ that > whether or not it's lots of code (which it is) and slow (which it can > be), that at least the API is easy enough to learn that it makes doing > simple things simple. Well I certainly think it is -- I'm sufficiently impressed with DateTime that I use it (and encourage colleagues to use it) for anything date- or time-related, without bothering to compare it with alternatives. > And most importantly, it handles all the niggling little corner cases, Certainly you've given the impression of having thought about these more than any of t'other date modules do -- and more than I want to have to think about them -- so I'm happy to trust the modules to get the write answers. Now that I'm quite familiar with DateTime I find it really easy to use. Getting there was a little bumpy in places -- not because the API was bad but cos I couldn't find where the bit I wanted to use was documented. However I don't have any specific complaints with your docs -- now that I look, all the things I couldn't see at first are clearly there. Possibly it's just that because DateTime does so much there have to be so many docs, which can be overwhelming at first. I'll ponder it some more, and if I come up with any positive suggestions I'll join the DateTime mailing list. (Some kind of intro tutorial/overview is one posibility, but I'm hesitant to suggest combatting the problem of overwhelming docs by adding yet more docs to them ...) Smylers
