On Fri, 17 Jan 2003, John Peacock wrote: > > my $formatter = > > DateTime::Formats::ISO8601->new > > ( class => 'DateTime::Implementation::TAI64' ); > > > > my $dt = $formatter->parse( ... ); > > That's OK, but too verbose for the average user, IMHO. It also leaps too deeply > into the API for my taste. I would suggest that the average user shouldn't need > to do anything more than > > my $dt = DateTime->new($datestring);
The default constructor is going take components (year, month, day ...), not a parseable string. > and have that do something useful for the majority of the trivial cases. I hate > to keep bringing up Math::BigInt, but the model is very close to what I think is > ideal. The base package works out of the box, but if you want better > performance, you add one line and your existing code works just the same, only > faster: > > use Math::BigInt; # implicitly uses Math::BigInt::Calc > use Math::BigInt lib => 'BitVect'; # faster backend > > and there is no need to change your existing code; I think it unlikely that > anyone would want to use more than one storage/backend module at the same time. So you're suggesting that DateTime.pm would be a factory class that might instantiate some other implementation, based on a previously set class variable? That's fine. > I also think I didn't explain my proposal sufficiently. I would argue that the > parser modules should be extremely thin and not full fledged constructors. All > that the parser would do is parse into a common format and leave the object > creation to the storage module. That's what DateTime::Formats::ICal does. But the common format is a named set of components. > which is exactly my $obj->as_array method would return. The reason that I Right, I just like named parameters. > suggested multiple possible parses is that some backends (like TAI) already have > a conversion from a specific external representation to their internal > representation. If the array of arguments is agreed to be the most likely I think for TAI this will have to deal with in the DateTime::Thingy::TAI64 module, not in a parser. There's no reason to burden parser implementors with having to create different sets of returns values just to handle various implementations. > "normalized" representation, I would actually have the Formats modules include > only a single function Parse() which would return the normalized relationship > (or undef if this parser cannot handle that date string). That's more or less how DateTime::Formats::ICal works, except it returns a DateTime.pm object. > > I think we should assume that creating a format/parse object will be > > one step, and actual parsing/formatting will be a different one. > > Why? It requires the average user to know far more about the internals than is > strictly necessary. Sure, it has to be available for those who need it, but it > shouldn't be the default interface. Cause it's the simplest, least bizarre interface. Everybody seems to have different ideas about how to make this more convenient, but absent any consensus I'll start with implementing the simple, least clever interface. > > I don't think the parser should be directly responsible for producing > > anything other than "DateTime.pm API-compliant object", which may or may > > not actually _be_ a DateTime.pm object. > > Well then we may be saying the same thing; I want the parser to generate a > normalized date format. I'm just saying that making the parser itself an object > is not _required_ to do that. It's not required, but making it an object may be needed for other things. For example, Date::Manip parsing is language dependent, so you may need one object for English and one for French. > Not at all. DateTime is the gatekeeper class; it contains any overloading code > (which you haven't really mentioned yet, have you?) as well as all of the Overloading code is in there. > 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. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
