[cc'ing back to the datetime list]
On Fri, 1 Jul 2005, Sam Vilain wrote:
I may have been quite vocal in the past about the practical failings
of DateTime for Perl 5, but as I'm sure we both know, the API has needed
Actually, I don't remember you saying anything, but maybe it was a while
back on the datetime list?
Perl 6 to be efficient from the outset; Param::Validate is now basically
built-in to the language, and having objects with many named properties
doesn't suck by design any more.
Yes, obviously Perl6 makes lots of OO things better. I think DateTime is
still pretty decent as far as Perl5 goes. Actually, my API problems with
it are more about conflating dates with datetimes and time zones, rather
than having more separate classes.
In a sense, by porting the DateTime test suite to Perl 6, I'm doing a
first cut of an API review/fix-up for you. I'm not very far through the
process, and I'm happy to proceed on the basis that you get the final
call on design decisions.
If you still prefer to call it DateTime (I like the abstract Date, and
Date::Gregorian myself), then I suggest you simply move the test cases
I've already done from the Date distribution, and I'll delete the
distribution and I'll instead focus my efforts on helping you with the
DateTime port.
Well, I think what you started already has some serious mistakes. For
one, the Huffman coding is backwards. You've used "Date" for a generic
interface, which is something that only calendar authors need to
implement, and then used Date::Gregorian for the thing that will be used
all the time. Short names like "Date" or "DateTime" should go to the most
commonly used bits, which is the Gregorian implementation. Interfaces
should have long names, like "Date::Calendar::Interface".
I also am not big on exporting functions like "date()" by default. I
think that's useful, but it definitely be on request.
Anyway, I think there's lots of time to play with this. I think you
should feel free to continue working on your code too, since there's no
need to have a unified effort at this time. If you'd prefer to work
together, that's fine too.
The really cool thing about developing Perl6 for Pugs at the moment is
that there's no way anyone can use it in production, so we're free to
break backwards compatibility at the drop of a hat ;)
My goals for working on DateTime for P6 are:
- Learn Perl6 - to that end I'm planning to write "ideal Perl6",
regardless of what Pugs supports, and then work backwards to a
Pugs-compatible version. This might also be helpful for Pugs, since I can
turn some of that code into TODO tests for Pugs.
- Explore a new DateTime API - right now I'm inclined to start with 3
core classes - Date, DateTime, and DateTimeTZ. DateTime would be a
datetime in the floating time zone, while DateTimeTZ would have a real
tz. I'm also thinking of trying to create a Time class, so that DateTime
is simply a container of a Date and a Time. The advantage here is that
authors of calendar modules which have the same 24-hour time system can
reuse that. Probably we'd need Time and TimeLS (leap second) or something
like that.
If other folks on this list are interested in participating, let me know.
I've already checked in a little bit of code under ext/DateTime in the
pugs repo, and I have some more I've been playing with on my hard disk.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
