Eugene van der Pijll wrote:
>Importantly, there are no "calendar-less" datetime objects. One may see
>this as an important difference between your approach and DateTime's;
>one may also see it as an implementation detail.
I think it's a very important architectural issue. To my mind a date
(or date+time) exists quite independently of calendars. Each calendar is
merely a way of representing these dates. The DateTime way makes it look
like the expression of the date is part of its identity. Of course, if
one has the right mental model, that it is the RDN that directly encodes
the abstract date identity, then it becomes clear that what the DateTime
(or DateTime::Calendar::Whatever) represents is not really the date but
some calendar-specific aspects of date representation.
Something you left out of your description: the date data in a DateTime
can be modified. Here once again the object is not representing a
date per se. If I consider the date that in ISO 8601 is represented
as "2006-07-18", it is meaningless to say that I "change its month
to August". That date is irrevocably in the Gregorian month July.
Yet DateTime lets me do
$dt = DateTime->new(year => 2006, month => 7, day => 18);
$dt->set_month(8);
print "$dt\n";
=> 2006-08-18T00:00:00
Of course I haven't changed 2006-07-18; all I've changed is the content
of a modifiable part of the DateTime object. So a DateTime actually
represents a *variable*, typed to hold a date (and time), viewed from
a distinctly Gregorian viewpoint.
My feeling on variables is that Perl already has a pretty good
implementation of them, and so building this facility into the DateTime
class is reinventing the wheel. And this one looks square: it doesn't
seem to be possible to modify the entire content of the variable in
one go except by a ->set call with eight parameters. I don't want
to single out DateTime for criticism on this point, though. A lot of
classes all over the place do the same thing. Even Math::BigRat, which
I curse every time I manage to accidentally modify one.
Anyway, having rambled a bit there, the point was that this is another of
the bits of baggage that comes with DateTime that I'd rather do without.
Which is why I started writing much plainer date-handling modules.
And a bonus point which falls out of this thread of discussion: I like
very clear documentation, and particularly a clear concept of what an
object represents. So I think it'd be good if we could come up with
sentences starting "An object of this type represents ..." to go at the
top of each class's documentation.
-zefram
