Re: Re: PACKAGE Proposal: Date_Calendar
| From: | Greg Beaver | Date: | Sat, 09 Aug 2003 20:01:55 +0000 |
| Subject: | Re: Re: PACKAGE Proposal: Date_Calendar | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-19457@lists.php.net to get a copy of this message | ||
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