On 20/10/06, Jasper Bryant-Greene <[EMAIL PROTECTED]> wrote:
The argument is that we should not unnecessarily break these people's code just because it makes no sense. Personally, I don't buy into this argument. Perhaps if their code breaks and there is a good explanation in the error message, they might start writing OO code that isn't nonsensical.
I fully agree with the sentiment that Jasper and others are making here. But I am torn between the purist and the pragmatic views. Ideally, the PHP Object Model should be more or less set in stone. Little or no choice for the user simply because choice is redundant and devisive. The issue with this is WHICH object model to use - there are many and not exactly the same. As the upgrade will break some users' code because it is not compatible or substandard in some way is a serious issue. As always, the answer is education/information. Make it well known and TRULY obvious what the issue is and WHY it has been changed well BEFORE the release. Not tucked away in a release notice or a change log which unless you where there at the time you have no idea what is going on. These sort of seemingly arbitary changes should be fully documented in the manual and maybe even within the PHP runtime error reporting system. Say a new error reporting option which can provide a link to examples of code and what should be changed and why. The why is the most important part. If a PHP upgrade has just broken a user's code, that user will want instant help in fixing it. What better than having a proper description of the error and what to do to remove it. Having an error for an upgrade and no explanation as to why it is now an error is a pain as you don't know the consequences of changing the code. Richard. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
