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

Re: [mplspm]: Picking up the ball

Thread Previous | Thread Next
From:
Matt Sergeant
Date:
January 12, 2003 23:43
Subject:
Re: [mplspm]: Picking up the ball
Message ID:
00bf01c2bad7$68c4d420$ed01a8c0@DOUGAL
From: "Ken Williams" <ken@mathforum.org>


> > On Thu 2003/01/09 16:04:04 CST, Dave Rolsky <autarch@urth.org> writes:
> >
> >> -- Provides simple date parsing ala Time::Piece->strptime.  Maybe
> >> throw in
> >> the functionality provided by Date::Parse?  Maybe make this a separate
> >> module.  Doesn't matter too much.
> >
> > Simple parsing needs to be in the base module (yyyymmdd at least).  I
> > would
> > prefer to see complex parsing put in a different module that could be
> > included (or not) based on if your application needs any complex
> > parsing.
>
> Yeah, the base module should accept several different non-ambiguous
> "canonical" formats such as the ones used in RFCs, and things like
> YYYY-MM-DD HH:MM:SS.  A supplementary module could handle fuzzy stuff
> like "3 days ago" and "a month from tomorrow".

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 suppose you could look at them as
constructors, but I'd disagree with that. A constructor should instantiate
an object via the simplest means possible. Everything else should go in an
external class (and if you like that class can inject methods into the base
class, but no date parsing whatsoever should go into the base class IMHO).

Matt.


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