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

Re: [mplspm]: Picking up the ball

Thread Previous | Thread Next
Dave Rolsky
January 9, 2003 16:35
Re: [mplspm]: Picking up the ball
Message ID:
On Thu, 9 Jan 2003, Chris Josephes wrote:

> > 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.
> I don't have any complains about it.  There's a chance that DateTime might
> cause confusion with Date:: and Time::, which would be a disadvantage.
> My only other suggested namespace would be "Horology::" which could be
> vague, but still conveys the purpose of the modules.

Clever, but really confusing when searching CPAN.

> > 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.
> For one thing, using an entirely seperate namespace would help to
> completely disassociate these modules from everything else in Date:: or
> Time::.  Otherwise, we end up making the problem worse by making people
> wonder if the modules created by this project are somehow compatable with
> what is already out there.

Yep, that's part of my goal.  Out with the old, in with the new.

> > - 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.  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.
> Why not just a DateTime object, like we already have a CGI object?

I suppose that's possible too.  I think the one thing the
cabal dislikes more than a new top-level namespace, is a single-level
module name in a new top-level namespace ;)

OTOH, if the goal is to provide a comprehensive set of datetime modules,
there's an advantage to having part of the suite be _the_ DateTime module.

> > -- It must work outside of epoch times.  Date::ICal - check!
> Can you elaborate more on your preference towards Date::ICal?  Are you
> saying that you have a preference towards the ISO 8601 time representation
> (ie. "20030109T1808") for the internal data structure of the date/time
> data?

Actually, Date::ICal stores things internally as julian days and seconds.
I like Date::ICal because its a good start for basic date OO stuff and
date math, that's all.  It happens to also parse the Ical format, which is
nice, but hardly a big deal.


House Absolute Consulting

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