Re: Call for Votes: PEAR::Calendar

From: Date: Fri, 24 Oct 2003 07:25:02 +0000
Subject: Re: Call for Votes: PEAR::Calendar
References: 1 2 3 4  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-22948@lists.php.net to get a copy of this message
Martin Jansen wrote:
On Fri Oct 24, 2003 at 08:5454AM +0200, Pierre-Alain Joye wrote:
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. <silly_story>
I learnt a long while ago about balancing theoretical limits of what abstracting down to compnents means.. As an Architect pushing the boundaries of CAD, (back in the days of 286's) I set about building a 3d model of a building.. As most of you living in countries where bricks are used will know.. the basic building element of a building is a brick... So I busily drew up a 3d brick (with holes and all)... and started stacking them up to build a building... Well, after the first 1000 or so. the machine started to slow down to a grinding halt.. The lesson.. - A wall may be made up of 1000's of bricks but representing it as a Wall with holes for windows is more sensible :) </silly_story> The problem here is that in terms of the problem 'A calandar', you could abstract it down to 1 object for each second.. - but since seconds/hours etc. are rather solid (eg. wont change much - I hope).. then making a overabstracted representation is usually an overkill.. (a bit like our famous 1 class per HTML Tag....) I dont dont see any problem with it going in as is, but it would be a good idea to try and make it use, if possible, the existing Date class (perhaps extended to handle time+generating sequences..) or to try and use one class to represent the DateTime compenent. <rant> Some of the things I found that often happen if you abstract too far - remembering 'what is where' becomes more difficult which in turn + ends up with accidental code repetition + can mean alot more documentation - security audits of 20 small files can be alot more difficult than 3/4 larger ones.. (mainly from the aspect of flow tracing) </rant> Regards Alan :) Regard Alan -- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com

« previous php.pear.dev (#22948) next »