On Sun, 12 Jan 2003, Yitzchak Scott-Thoennes wrote:
> I need to find more time to read through the flood of messages...but
> wanted to mention right away that things look to be going astray.
> Apologies if it is not so.
I don't think so, but you may ;) In fact, I'm generally pretty happy with
the way its going.
> What's the goal here? If it is creating a base class for date/time
> modules to standardize on, that won't work. I don't think the authors
> of the existing modules are interested. That way only leads to the
> creation of Date::Yet::Another::Module.
Yes, the goal is to create a _set_ of modules that interoperate with each
other, something that none of the existing modules do.
Given that goal, I've so far been primarily focused on getting a base
(Gregorian) datetime object with a rich, consistent, and usable API.
As to whether the other module authors are interested, I do know that at
least a few are, including Rich Bowen and Flavio Glock. Others may become
interested if the project keeps going and producing useful code.
But here's what I said about other module authors in my first message
about this project:
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!
And I stick by that. If the authors of existing modules are not
interested in seeing a _set_ of useful datetime modules that work
together, then they can go play in their own sandbox.
For me, success in this project will mean that people will think of the
"DateTime suite" when they think of how to handle date and/or time
problems with Perl. IOW, I want to make the existing modules for this
largely obsolete. If that happens, other module authors may eventually
want to become involved in this project, and that'd be great.
> If it is creating a module to provide some glue between existing
> modules, great--but make sure that's the focus. Does that need to be
> more complicated than:
>
> $from_object = Date::ICal->new( ical => '19971024T120000' );
> Date::Glue::->make_a('Date::Calc::Object', $from_object)
>
> where Date::Glue understands the get/set API of as many as possible of
> the OO date modules out there?
I'm really not too interested in this, but if somebody wants to do it,
that's cool. My guess is that this sort of thing just wouldn't be used,
because it still requires you to know a dozen different, incompatible
APIs.
> Another goal I see as worthwhile would be a non-partisan document
> comparing the strengths and weaknesses of the existing modules, with a
> link to it from the date and time categories on CPAN.
I actually surveyed a _lot_ of existing modules before deciding on this
path, and I have some very off the cuff writeups of my impressions of
them, if you're interested in putting together such a document.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
