develooper Front page | perl.datetime | Postings from January 2003

Re: Parser/Backend API proposals

Thread Previous | Thread Next
From:
John Peacock
Date:
January 17, 2003 19:10
Subject:
Re: Parser/Backend API proposals
Message ID:
3E28C57F.8070807@rowman.com
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-5747


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About