Re: Call for Votes: PEAR::Calendar

OK - this wasn't meant to kick off a major debate but perhaps I can clear things up by explaining a few things about the way Calendar is designed, if everyone's got time to read a little. >> > I agree. Implementing little tiny classes in php only to strictly >> > follow a OO model sounds always bad to me. >> >> What's so bad about using object oriented paradigmas? That not only >> breaks down the class into small pieces, but also ensure that the code >> can be more easily extended and maintained. > > In a compiled langage, it's not a problem. In interpreted langages, > having tons of small files with small classes is not that good. Nothing > against the OO itself... If each class is in a seperate file, simply to have every class in a seperate file, then I agreed that it's not good. But there's a reverse to this argument - if some file you include contains one class you actually need and 10 you never use, unless you've got some kind of cache (and I guess 95% of PHP's users don't on the typical web host), you're paying the price of parsing the lot on every page request. I've tried to design Calendar to allow users to work with the classes they need without having to "pay the price" for the stuff they don't need. For example I imagine less people will be interested in working with the Calendar_Minute and Calendar_Second classes than with a Calendar_Month, so better to have these as seperate files for when needed. Also I make sure to "lazy include" where ever possible - for example if you have an instance of Calendar_Month and you need the get Calendar_Day's from it, the Calendar_Day class file is only included at the point you call the Calendar_Month::build() method. There are other instances which are more about re-use and maintainability, where a class finds itself in a seperate file because it's needed by more than one other. For example the "protected" Calendar_Table_Helper class is needed by Calendar_Month_Weekdays, Calendar_Month_Weeks and Calendar_Week so is in a seperate file. Originally this code was reproduced in all three classes. There is one culprit which could (and will) be moved to the Calendar.php file which is Calendar_Engine_Factory.php - that was something I added later but is now used on every request. Also, the Calendar_Engine_Interface class is not used at all - it's simply there to state what a Calendar_Engine should implement (for people who want to add engines like one based on PEAR::Date) - saves people time allowing them to copy and paste. Like I say, have been working on this one on and off for about six months now, tryng to get it feeling "right". If there's ways to improve performance I'm definately interested (think a package like this which doesn't directly render any content has to be as fast as possible) but I'm fairly confident in saying it will need more than a glance at the code to find further optimizations, without sacrificing functionality.