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 [EMAIL PROTECTED] list, however. ]
Cool, I've subscribed.
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.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 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.2. Use the DateTime:: namespace. The [EMAIL PROTECTED] 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.
- 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 forI 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.
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.
-- Simple OO interface for getting pieces of the date, formatting forToo 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.
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.
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.-- 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.
-- Provides simple date parsing ala Time::Piece->strptime. Maybe throw inYeah, maybe a simple parsing method like strptime(), but otherwise there should be a separate (factory?) class, IMO.
the functionality provided by Date::Parse? Maybe make this a separate
module. Doesn't matter too much.
Completely separate. I've steered clear of this module whenever possible because of the overhead.-- Complex date parsing to be provided by a separate module (refactored Date::Manip, I hope).
-- Real timezone support (Olsen database), something totally lacking inYes! This is essential in the base class. It should also be aware of and affected by $ENV{TZ}, too, of course.
Perl right now. We need to finish up the Date::ICal::Timezone stuff Jesse
pointed me at.
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:-- 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.
$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.
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.So, who's ready to chew ass and kick some bubble-gum?!
Heard from Rich, yet?
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
