On Mon, 14 Jul 2003, John Siracusa wrote: > > That is another reason why I suggest not having the parser() and parse() > > methods in DT at all. For people who never need to parse random date strings, > > they only "use DateTime;" and they are done; everyone else does "use > > DateTime::Format;" as well. The latter "use" would then take an array of > > additional Format modules to use when parsing (if desired). > > Why not have them at all? Okay, so defer parser class loading until the > last minute. Then all you have is a dozen or so more lines of code in > DateTime. Is that going to kill you? :)
No, but it might kill me ;) 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. > 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 ... -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
