On Fri, 10 Jan 2003, dLux wrote:
> I have checked the Date::ICal module, which addressed most of the issues
> I have faced in the development of Class::Date. Although it does not
> solve all of this, the module implementation is quite good, ideal for
> a DateTime base class.
I think it certainly does enough to start with, and adding a richer API
(similar to Class::Date or Time::Piece) is trivial, because all the needed
information is present in the current implementation.
> Some ideas, which can be borrowed from Class::Date:
>
> - pluggable parsers
I alluded to this when I talked about complex parsing. Basically,
anything beyond bare bones parsing (strptime plus _maybe_ the formats
Date::Parse handles) belong in a separate module. Those modules will
parse a string and create a DateTime object. So there's no "plugging",
per se. You just load the module you need.
> - Subclassability
I think this is important too, though I actually hope that there's not a
profusion of subclasses for the core datetime object, since I think much
of what people use subclassing for is better handled by having common
APIs, or by decorators, etc.
> - timezone-handling
Yes, I talked about this. It should use the Olsen database to get _real_
timezone. I don't think it can rely on POSIX stuff since it needs to work
across as many platforms as possible. Jesse Vincent began some code to us
the Olsen db from Perl. It's in the reefknot CVS as Date::ICal::Timezone.
> - configurability with localizable variables
If you're talking about the stuff in Class::Date like
$Class::Date::RANGE_CHECK, I _really_ dislike this interface. This sort
of stuff should be settable on a per-class and per-object basis, not by
exposing global variables.
But I'm sure some of the things that Class::Date handles via these
variables will need handling, like the above-mentioned range checking.
> - exportable "datetime", "localdatetime", "gmdatetime" functions for
> short-cuts of the constructors.
I like the way Time::Piece overrides localtime and gmtime. I don't see a
need for a whole mess of exported functions, though, and I'm inclined to
export nothing by default.
> - Object for an invalid date
Can you explain why this is useful?
> Syntax proposals, which are besides the syntax of Date::ICal:
>
> - $date + { year => 3 }
> - $date + [ 3, 0, 0 ]
I think this'd something that belongs outside the core datetime object,
though if it's widely desired then it can be in the core. I don't feel
strongly one way or another, but this is a small detail that need not be
addressed right now.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
