Re: Call for Votes: PEAR::Calendar

[Perhaps I can mail straight to the list now - if not will re-post this tonight] > Harry, you know what I will say on this :) ;) > > 20 classes to do a calender is a little of an overkill (reminds me of > the joke in an eddy murphy movie about using AK47 to shoot game) OK - the reason for doing this is mainly performance [plus I find it easier to maintain but may be I'm insane] - there's enough variation between say building a list of hours in a day and a list of days in a month to mean that bundling them together has a significant impact on performance both at the script parsing and script execution stages. Back when I started this (about 6 months ago) it was only two classes but to generate a tabular month, for example, it was taking about 0.5 to 1 seconds (now improved by a factor of 10). In other words, when you create a month and build it's days, the number of classes involved are actually only 4: Calendar, Calendar_Month, Calendar_Day and Calendar_Engine_UnixTs (plus a static call through Calendar_Engine_Factory) - the rest are not even parsed. Also these class files have become alot more lightweight (fewer lines of code). > > I like the idea of having a class to contain the date/time, but a single > slightly larger class that handles all time/date combinations would make > sense.. > eg. > $date = Calendar_DateTime::make(2000,10,1); > $datetime = Calendar_DateTime::make(2000,10,1,10,15,1); > > (using func_get_args() to determine how may args....) > > there seems alot of repetition in all the Day/Month/Year classes... that > would be eliminated by this.. > > alot the nextDay/nextYear may be handled better by something like > $nextday = $date->make($date->year, $date->month, $date+1); > $nextmonth = $date->make($date->year, $date->month+1, $date); > > that way > a) you dont have to document alot of very simple, & obvious methods > b) the user doesnt have to remember all the methods.. > > (basically it's pretty much how mktime works....) That's very doable with (you guessed it ;)) another class - should be no problem to have something like the base class of PEAR::DB to fetch what's needed. > > Other points (partly from the FAQ) > - using define rather than require_once > Thats one of the PEAR coding standards.. - you probably dont gain very > much doing it that way.. - from what I remember they both do the same > thing internally (look up a hash table).. OK - can change that. Reason was I get wierd things happening with require_once - the same statement is sometimes fast and other times takes "ages". Define/require seems to give consistent performance. May be someone who knows the source can clear that up for me. > > It would be nice to handle non-unixtime dates like < 1970.. - but I > guess that has to wait until we have someone bothered to write the > algoritmns to do it... As mentioned, that should be possible. Origionally I had all the calls to date() / mktime() embedded in the code but these have all be externalized into the "Calendar_Engine" classes (on Greg Beaver's request). From glancing at what PEAR::Date is supposed to do, it looks like it should work well (assuming it isn't broken of course). Anyway - if there's a major outcry against so many classes, how about this - add the the first version of the package as is so people can use it then merge it all together before it's a stable release - should be possible without having to break APIs, allowing stuff like HTML_Calendar to get started.