On Monday, January 13, 2003, at 01:07 PM, David Wheeler wrote: > On Sunday, January 12, 2003, at 11:42 PM, Matt Sergeant wrote: > >> Parsing should not be in a base date time class though - it has no >> place there. It should *return* a base date time object, but putting >> generators in the same class doesn't make sense to me. > > I disagree. I think that some very fundamental parsing needs to go > into the base class. You should be able to construct a DateTime object > for whatever date and time you need, and to do that, it has to be able > to parse a date/time argument. But nothing fancy, just a few formats > should be supported in the base class, including epoch time, ICal, and > maybe ISO 8601. Other than that, I agree that all other date parsing > should go into another module. What's the benefit of making this distinction between core and "other" formats? Why not define a parser interface and include the basic formats as modules in the main distribution? This type of design should encourage separation of concerns, and help to avoid monolithic implementations -- the current DateTime::new sub is over 100 lines long... The overhead of one more method call seems like a small price to pay. my $dt = DateTime->new( ICal => '20030113' ); # Causes DateTime to load the ICal format module and request that # it parse the data and return it in a standard numeric form. # Equivalent to the following: require DateTime::Format::ICal; my $dt = DateTime->new( rd_sec => DateTime::Format::ICal->parse_into_ratadie_and_seconds('20030113') ); The same type of architecture could also facilitate supporting arbitrary stringification into whichever format was desired... -SimonThread Previous | Thread Next