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

Re: Picking up the ball

Thread Previous | Thread Next
David Wheeler
January 9, 2003 17:56
Re: Picking up the ball
Message ID:
On Thursday, January 9, 2003, at 02:04  PM, Dave Rolsky wrote:

> [ CC'd to the Mpls Perl Monger list, Matt Sergeant, and David Wheeler, 
> all
> of whom have expressed some interest in the topic.  I'd suggest that
> further discussion be solely on the list, however. ]

Cool, I've subscribed.

> 1. Stop herding cats.  If existing module authors don't want to play,
> then screw them.  I don't want to spend lots of time arguing about
> namespaces and whether modules should move to a new namespace or any
> such crap.  I want to have a suite of modules that actually work
> together, instead of a big mess of random crap!

I agree. Interested parties should participate for as long as they're 
interested, and others can continue to do what they like. Just as the 
DBI didn't make it possible for oraperl, sybperl, pgperl, etc. to 
interoperate, but created a new unified API, I think that the same 
should apply here. We should create something that's so good and 
flexible that people *want* to use it. Trying to get everyone to agree 
will be a waste of time.

> 2. Use the DateTime:: namespace.  The cabal doesn't
> like it?  That's nice.  Their buy-in is nice, but lack thereof does
> not prevent success.  And in my experience, when presented with
> working code that's being used by a bunch of people, they may accept a
> namespace previously deemed unacceptable.
> Why a new top-level namespace?  Well, what's the difference between
> Date:: and Time::?  Not much, in most cases.  It seems like the
> authors of these modules mostly picked one at random.  There are a few
> exceptions, like Time::HiRes, but other than that, it's ridiculous.
> Moreover, the DateTime:: space is empty except for one module, and so
> it won't be cluttered by a million overlapping older modules.  So it
> provides a nice psychological benefit of dropping the baggage.

I agree with all of these statements. While I'm not fond of the 
"DateTime" moniker myself, I think that the namespace issue is one of 
the least important parts of the problem. Start with DateTime (with as the base class, IMO), and change it if we think of 
something better later (kind of as Mat chnaged "Time::Object" to 
"Time::Piece"). 'Nuff said.

> - DateTime::Object - Yeah, I know Rich hates class names that describe
> the implementation, so maybe DateTime::Base.  I don't care too much.  
> The
> namespace should make it should be obvious that this is the basic 
> building
> block for all datetime functionality in the suite.

I agree with someone else that it should be

> A good candidate for
> this is the existing Date::ICal code, with a bunch of the Time::Piece
> convenience methods thrown in for good measure.  The only thing 
> Date::Ical
> needs is to add support for fractional seconds.

I need to check out Date::ICal. I had assumed that it was just for 
doing stuff with the ICal format, not that it was a general date/time 
munging class. I'll have to check it out. Time::Piece has been my 
favorite for a while, so a combination of the two may well be the ideal 

> -- Simple OO interface for getting pieces of the date, formatting for
> display, etc.  Date::ICal and Time::Piece have a good API for this
> already.  I think Time::Piece may have _too many_ methods, but 
> Date::ICal
> doesn't have quite enough.

Too many methods doesn't bother me -- just use the ones that you need, 
and be grateful when you need one you hadn't expected and it's already 
there. But above all, I think that it should be very fast and very easy 
to use.

> -- It must work outside of epoch times.  Date::ICal - check!
> -- It should handle fractional seconds.  Based on a brief perusal of
> Date::ICal, I think this can be added without too much difficulty.

It'd be okay with me if this was in a subclass. But if it's easy to add 
and doesn't add much overhead, then cool.

> -- 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.

Yeah, maybe a simple parsing method like strptime(), but otherwise 
there should be a separate (factory?) class, IMO.

> -- Complex date parsing to be provided by a separate module (refactored
> Date::Manip, I hope).

Completely separate. I've steered clear of this module whenever 
possible because of the overhead.

> -- Real timezone support (Olsen database), something totally lacking in
> Perl right now.  We need to finish up the Date::ICal::Timezone stuff 
> Jesse
> pointed me at.

Yes! This is essential in the base class. It should also be aware of 
and affected by $ENV{TZ}, too, of course.

> -- Date calculations ala Date::Calc.  Some of what Date::Calc provides
> doesn't really return _dates_ per se, and that can go in a separate
> module.

Calculation methods should accept DateTime objects for their arguments, 
of course. Having the class also use overloading would be very cool. 
Hrm, then it would probably have to be a subclass of the DateTime class 
that did this stuff. Or, no, the calc stuff should be *added* to the 
DateTime class via in implementation of the decorator pattern. This is 
because it makes sense to make the calculate methods apply to DateTime 
objects themselves:


Just a thought. Because there are likely to be quite a few different 
modules that may need to be used in a different project, many of which 
might otherwise subclass DateTime, I think an application of the 
decorator pattern might really be beneficial here. But regardless of 
the extensibility model we adapt, it should be *very* easy to use.

> -- Complex parsing?  "Every Tuesday in March from 3:30PM - 5:30PM"  
> That'd
> be cool, but not crucial.

Perhaps in a subclass or decorated.

> And here's a set of goals:

<snip />

> Ok, forget 4 & 5.  But I think the rest are good ideas.

Yes, agreed.

> So, who's ready to chew ass and kick some bubble-gum?!

I'll help where I can. I'm pretty busy these days, but I'll at least do 
some kibbitzing, probably provide some tests here and there, and code 
when possible.

Heard from Rich, yet?



David Wheeler                                     AIM: dwTheory                                 ICQ: 15726394                      Yahoo!: dew7e

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About