> For example, the set() method will attempt to unconditionally call set() > on the base object. But if the base is 2003-02-10T00:00:00 and one calls > "$dti->set( day => 30 )" then we'll get a validation error. But if the > incomplete object only has a known year, there's no reason to error out > (yet). And the docs say you can do "set( day => undef )" but that will > clearly break badly.
It might be better to just use utc_rd_values() and have one object. DT::Calendar::Incomplete might be a good name too. > So clearly this needs fixing. I'm also not too keen on the way it stores > the datetime data in both the incomplete object and the base object. It > should all be in one spot, ideally, otherwise we'd end having > to re-implement things like "quarter" and "day_of_week" and so on. My original vision was to just make this a subclass/decorator of DT with some attributes tacked on. I'm not sure how practical that would have been. At least we're learning something from the current implementation. > Also, the whole attempt to be base class agnostic is only half there, and > it makes a bit of a mess of the code. I'd rather take it out, because > really implementing it is quite hard, and just makes for overly complex > code. I think auto-generating incomplete classes for other calendars is a > simpler solution, if it's ever needed. There should be a standard method to get the 'units' of a calendar out specified in rd days/seconds. That would make it fairly easy to generate a wrapper. Of course theres no reason we couldn't just attach attributes to other calendars as well. -J --
