On 7/14/03 3:36 PM, Dave Rolsky wrote: > I'm getting concerned about DateTime bloating, not so much in terms of > code, but in terms of features. Every feature requires more docs, and > more docs means that it becomes harder and harder to figure out how to do > the one thing _you_ want DT.pm to do.
DT is only as complex as it needs to be, IMO :) And a good "examples" or "tutorial" section in the docs will go a long way towards letting users quickly and easily figure out how to do most common tasks. Of course, one of those common tasks is probably going to be parsing simple date formats. As a user, would you rather be told, "Go explore the various the DT::F::* modules until you find what you need. Then download and install that module, load it, and use it to parse your dates. Then come back to these docs to learn more about those date objects."...or..."You can probably just use parse() if your date formats are simple. Here's an example, and here's a link to the parse() entry in this document. If your dates are more complex, then see the DT::F::* modules and the parser() method." >> I think this is a very important feature. If DateTime didn't have >> strftime() already, then maybe I'd buy the argument that "DateTime is just >> an object representation of dates and doesn't deal with string input/output" >> (although that'd make DateTime a lot less useful, I think). As things >> stand, the lack of a parse() method represents a gap in functionality, IMO. > > Yeah, maybe ... "Search your feelings, you know it to be true!" :) -John
