Front page | perl.datetime |
Postings from January 2003
Dave Rolsky wrote: >> my $dt = DateTime->new($datestring); > > > The default constructor is going take components (year, month, day ...), > not a parseable string. 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. 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. >>No question. Any implemention class will inherit all of the derivable methods >>and only implement/override the minority of primitive methods (like $obj->year >>for example). > > > Can you explain what the class hierarchy for DateTime.pm-API objects would > be? > > Right now I'm thinking: > > DateTime.pm - implements reference API, with completely functional > internals > > DateTime::Implementation::TAI64 - implements same API. Inherits from > DateTime.pm and overrides some methods. > > Clearly you're thinking of something else but I don't understand what. > > 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. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747Thread Previous | Thread Next