note 50626 added to language.oop5.decon

> To caliban at darklock dot com: Why not just define > a dummy constructor Because you don't always get to modify your base classes. Once you get beyond the "build to suit" range of software development, you end up having to work with other people's code, and sometimes you just plain can't change it. When Bob is in charge of making changes to that object, you can't add a dummy constructor. You have to tell Bob to do it, and until Bob does it, you don't get it. So if you want to hit your deadlines, you don't count on Bob caring enough about your job to make the changes you want... you work around it. It might be convenient for *you* to have a constructor on that object, but when you're only one of several thousand people that are using it, your convenience isn't generally among the design criteria. Smaller projects where you can add whatever you want wherever you want will not have this problem, in which case the dummy constructor is indeed a better solution. ---- Manual Page -- http://www.php.net/manual/en/language.oop5.decon.php Edit -- http://master.php.net/manage/user-notes.php?action=edit+50626 Delete: added to the manual -- http://master.php.net/manage/user-notes.php?action=delete+50626&report=yes&reason=added+to+the+manual Delete: bad code -- http://master.php.net/manage/user-notes.php?action=delete+50626&report=yes&reason=bad+code Delete: spam -- http://master.php.net/manage/user-notes.php?action=delete+50626&report=yes&reason=spam Delete: useless -- http://master.php.net/manage/user-notes.php?action=delete+50626&report=yes&reason=useless Delete: other reasons -- http://master.php.net/manage/user-notes.php?action=delete+50626&report=yes Reject -- http://master.php.net/manage/user-notes.php?action=reject+50626&report=yes Search -- http://master.php.net/manage/user-notes.php