Front page | perl.datetime |
Postings from January 2003
Re: [mplspm]: Picking up the ball
Thread Previous
|
Thread Next
From:
Dave Rolsky
Date:
January 9, 2003 16:35
Subject:
Re: [mplspm]: Picking up the ball
Message ID:
Pine.LNX.4.51.0301091831590.25009@urth.org
On Thu, 9 Jan 2003, Chris Josephes wrote:
> > 2. Use the DateTime:: namespace. The modules@perl.org 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 modules@perl.org
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.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
Thread Previous
|
Thread Next