Re: Re: PACKAGE Proposal: Date_Calendar

Hi Greg, Think you're absolutely right. I have to be frank that timewise, at least for the near future, I won't be able to implement a Julian "calculation engine" but what I can to, as you point out, is factor out all the specific calculatations to a seperate class hierarchy that is easy to replace with an alternative, depending on the problem. That means it should be possible to tell the library to use Julian (or otherwise) timestamps instead of Unix timestamps. I'll also keep in mind the design objective that it should be possible to have the library generate, say, a Chinese calendar (although no promises that $year = new Year('Rat') is ever going to work ;). Guess from that persective it would be a good idea to have a seperate namespace "Calendar" - I don't want to become maintainer of a massive library so if it's possible to develop calendar "plugins", under that namespace, that other people can maintain, would be perfect. Reckon making those changes won't take too long and probably won't significantly effect the current API, from the perspective of someone using the classes to render HTML. Let sound good enough for qualify for a +1? All the best, Harry On Sat, 09 Aug 2003 16:01:55 -0400, Greg Beaver <greg@chiaraquartet.net> wrote:

Stefan Neufeind wrote:

Well, I guess Harry will try his best. But how about making a first step (devel-release) and then pushing things forward? That seems a better idea to me since you "can't change the world in one day". If you can change it step by step I guess thats the way to go.

Hi Stefan, I'm not trying to change the world in one day, or unnecessarily delay your HTML_Calendar. Harry needs to modify the source to make it PEAR-CS compliant anyways, why not add in at least the possibility of having this package work with other dates? As I said in the last post, it will only require changing the mktime() calls to $this->base->mktime(), and allowing the mktime() method to be extensible. Even if the first release doesn't have support for another base time representation, it will at least be possible to do this in the future. If the mktime() calls are hard-coded into Calendar, this is not possible. I also said I'm willing to help code it, so let's let Harry answer for himself. Rushing to a release pre-maturely is a bad thing if the API and issues with extensibility are not thought deeply about, especially when there will immediately be dependencies on the code. All of us have experienced releasing something and then writing in circles to work around our own design choices without breaking BC. I'd like to avoid this, if possible, for any new package in PEAR. Greg