Re: Re: PACKAGE Proposal: Date_Calendar

Hi Harry, Harry Fuecks wrote:

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 ;).

I think I can live without a promise of this feature ;)

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?

These changes are exactly what I would like to see in the initial release. I agree with everything you said here, Calendar needs to be a new namespace so you aren't overloaded. I'd give +1 now, but I'll wait for the official package to go with protocol. Consider that +1 a certainty, though. Greg