Front page | perl.datetime |
Postings from January 2003
Re: Picking up the ball
Thread Previous
|
Thread Next
From:
David Wheeler
Date:
January 9, 2003 17:56
Subject:
Re: Picking up the ball
Message ID:
C0412BBC-243E-11D7-AAD0-000393D9436A@wheeler.net
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 datetime@perl.org 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 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.
>
> 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
DateTime.pm 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 DateTime.pm.
> 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
situation.
> -- 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:
$dt.delta_days($dt2);
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?
Regards,
David
--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Thread Previous
|
Thread Next