Front page | perl.datetime |
Postings from January 2003
On Fri, 17 Jan 2003, John Peacock wrote: > That's where we part ways, then. I would rather see the contructor DWIM if > handed a string. I suppose I can write a class which does, in fact, wrap the > parsing and object creation into a single call, say DateTime::Parse. Just to clarify, I don't object to the idea of constructing objects from whatever set of params you want. I do object to having it all done by one method! So if you had "DateTime->from_string" that's fine. The main reason for this is allowing multiple sets of unrelated parmeters to a single method makes validating input _really_ painful, and users can get confused and give you parameters from multiple sets. It's a mess. If you take a look at the CVS code, you'll see that the DateTime new() constructor is now very simple. There's also a from_epoch() constructor, and a now() constructor (which calls from_epoch). Nice and orderly. > Have you decided to require all components to be defined in order to be > well-formed? In other words, if I only care about dates, can I undef all of the > time related components and have the right thing happen? At this point, I am > not arguing one way or another; I can see both being useful. Obviously, if I > request an output that contains time fields, the undef would need to be rendered > as 0's, but the information that certain fields were not specifically > initialized can be useful. Time defaults to midnight if not given. > That *is* what I am thinking as well. I'm not arguing _that_ point, just > whether the parsing also needs to be an object. I view the parsing more as a > filter than anything else; get the messy realworld data into a standard form so > I can do something useful with it. I think we agree and arguing over a _very_ tiny API issue ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/Thread Previous | Thread Next