On Sun, 20 Jul 2003, Claus F�rber wrote: > The most important difference is that I'd like DateTime::Incomplete to > actually BE a DateTime: Methods defined by DateTime would just behave as > if the base date had been set to 1970-01-01T00:00:00.00...; new methods > (or parameters) would make up the interface to the precision fields. > So parsers could just return a DT::I object and calling code that does > not expect partial dates would still kinda work.
The phrase "still kinda work" sets of my alarms. I think parsers that can return DT::Incomplete objects need to be very explicit that they do so. In fact, we might even want to insist that "parse_datetime" _always_ return a complete object or fail, and then offer an additional "parse_incomplete_datetime" method or something like that. Otherwise people will consistly have to test the returned object's type to make sure it contains the information they need. Since for _most_ people, incomplete dates will be an error condition, I don't want to force them to deal with them. > On the other hand, it would not be able to handle different calendars. > But then, I wonder if it's possible to just build a wrapper for all > DateTime::Calendar::* modules. Probably, all modules except > DT::C::Julian and DT::C::Christian (which do use 'year', 'month', 'day' > like DateTime) will need an own partial class anyway. Yeah, the idea that core code should be shareable among different calendars is mostly bogus. Ignoring the Julian and Christian modules, most other calendars are sufficiently different that they don't really match up well method-wise with the core code. Java tries to shoehorn them all into one API and it's a horrible disaster. Let's not repeat that mistake. If people _really_ need a DT::Calendar::Mayan::Incomplete, it'll have to stand on its own. OTOH, I really doubt that most calendars will need such a thing. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
