Re: porting DateTime to Perl6
On Fri, Jul 22, 2005 at 10:46:24PM -0300, Flavio S. Glock wrote: Dave has started DateTime, and I'm working on Pugs modules DateTime::Span, DateTime::SpanSet and a new module called DateTime::Recurrence, as well as the base modules Span, Recurrence, and Set-Infinite. Everything is under the /ext directory. Dave has started down a path for something which is/will be engineered very differently from the p5 version of DateTime. I'm not saying this is a bad thing, especially in the long run, I'm just trying to start a discussion point on what the 'best' way to do things for the time being is. Hopefully sparking the interest of people (other then just Dave to work on the p6 implementation (myself included). I'm splitting the modules into a functional implementation class and a OO api class. I found this separation useful when writing tests and optimizing. The functional base objects can be memoized if desired, and it allows to have multiple implementations under the same api. That does seem reasonable. Those modules don't have the complex interdependencies that DateTime has with timezones, locales etc. I think it will be a large enough effort to get the DateTime - DateTime::TimeZone interaction working under p6 without going through a major design overhaul at the same time. Then again, I do tend to be a pessimist... Cheers, -J -- pgpvXUuBcIYAr.pgp Description: PGP signature
Re: porting DateTime to Perl6
On Fri, 22 Jul 2005, Joshua Hoblitt wrote: Dave has started down a path for something which is/will be engineered very differently from the p5 version of DateTime. I'm not saying this is a bad thing, especially in the long run, I'm just trying to start a discussion point on what the 'best' way to do things for the time being is. Hopefully sparking the interest of people (other then just Dave to work on the p6 implementation (myself included). Well, don't take what I've written so far as gospel. For example, the fact that it doesn't use rata die internally at the moment doesn't mean anything other than I was too lazy to rewrite the rd-ymd stuff in P6 yet. Anyway, if some folks want to work on a more literal port of DateTime to P6 I'd be happy to rename the stuff I've done so far to DateTime6 or something like that. The great thing about writing for pugs is that no one can complain when you break backwards compatibility ;) -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
porting DateTime to Perl6
Hi Folks, It appears as if Pugs is very close to being able to host a major framework like DateTime. I think that it's 'time' to start considering porting DateTime to Perl6. Even if for no other reason then to help debug Pugs. The big question that I believe needs to be settled is do we make a 'straight' port of DateTime to Perl6 or do we take the opportunity to do some re-engineering? My opinion: While there are several things in DateTime's API/implementation that I'd like to see reworked I'm fearful of falling prey to Second System Syndrome. I also feel like DateTime hasn't been around long enough to have felt out all the issue's that could/should be addressed in an API change. My proposal is that the initial port be a straight across translation of DateTime to Perl6 and that serious re-engineering work be put off for DateTime2. Thoughts? Comments? Cheers, -J -- pgp4m3xSphVUJ.pgp Description: PGP signature
Re: porting DateTime to Perl6
Dave has started DateTime, and I'm working on Pugs modules DateTime::Span, DateTime::SpanSet and a new module called DateTime::Recurrence, as well as the base modules Span, Recurrence, and Set-Infinite. Everything is under the /ext directory. I'm splitting the modules into a functional implementation class and a OO api class. I found this separation useful when writing tests and optimizing. The functional base objects can be memoized if desired, and it allows to have multiple implementations under the same api. - Flavio S. Glock 2005/7/22, Joshua Hoblitt [EMAIL PROTECTED]: Hi Folks, It appears as if Pugs is very close to being able to host a major framework like DateTime. I think that it's 'time' to start considering porting DateTime to Perl6. Even if for no other reason then to help debug Pugs. The big question that I believe needs to be settled is do we make a 'straight' port of DateTime to Perl6 or do we take the opportunity to do some re-engineering? My opinion: While there are several things in DateTime's API/implementation that I'd like to see reworked I'm fearful of falling prey to Second System Syndrome. I also feel like DateTime hasn't been around long enough to have felt out all the issue's that could/should be addressed in an API change. My proposal is that the initial port be a straight across translation of DateTime to Perl6 and that serious re-engineering work be put off for DateTime2. Thoughts? Comments?
Re: porting DateTime to Perl6
On Fri, 22 Jul 2005, Joshua Hoblitt wrote: It appears as if Pugs is very close to being able to host a major framework like DateTime. I think that it's 'time' to start considering porting DateTime to Perl6. Even if for no other reason then to help debug Pugs. The big question that I believe needs to be settled is do we make a 'straight' port of DateTime to Perl6 or do we take the opportunity to do some re-engineering? Well, I've already started a bit, but mainly to experiment with new APIs. My thought is that since there's a lot of time before Perl6 is really available, there's no reason not to experiment. addressed in an API change. My proposal is that the initial port be a straight across translation of DateTime to Perl6 and that serious re-engineering work be put off for DateTime2. If you want to work on this that's cool, but I want to play with new API stuff. I think there's a couple things I'd like to fix: - date-only stuff is complicated by the presence of times, time zones, leap seconds, etc. - there should be a datetime class with no knowledge of time zones or leap seconds (floating time zone only), because lots of people want to do simple datetime math - a more complex datetime+timezone+leap second class that does everything right, but offers a much complex API. For example, there probably need to be separate date math methods that operate on UTC or local aspects of the datetime. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/