Re: DateTime.pm on a Diet
On Thu, Jul 21, 2005 at 01:54:30PM +1000, Rick Measham wrote: I want to wrap this up and release so there's 24 hours to finalise the name. Here's the names I like thus far: DateTime::LazyInit (from John Siracusa) DateTime::Mock (from Joshua Hoblitt) DateTime::Diet (original development name based on the subject) If anyone has any interest, please comment in the next 24 hours (based on the timestamp of this message) I'm not trying to beat this thread to death but it just occurred to me that this is following the proxy design pattern. So DateTime::Proxy might be a good name as well. Of the three name in your list I think I like DateTime::LazyInit more than the others. Cheers, -J -- pgpRyOZFJZvo4.pgp Description: PGP signature
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 ===*/
