Re: PHP5 only sure .. E_STRICT?

> Le mercredi 12 juillet 2006 00:50, Lukas Smith a écrit : > Markus Tacker wrote: > > So, they say what's E_STRICT will not work in PHP6. What's not may > > become E_STRICT in future releases of PHP. > > This solution would not require any large changes in PHP internals. They > would simply need to make sure that all new E_STRICT messages follow > this defined schema. > Why makes php code hugly to track E_STRICT programmer errors ??? If you realy want to get rid of the E_STRICT error : => Add that before the pear call (require, include) : //FIXME : workaround until PEAR MDB2 becomes php5 E_STRICT ready $old = error_reporting(E_ALL); => Add that after the pear call //FIXME : restore old E_STRICT mode error_reporting($old); And fix the pear E_STRICT errors... That easy 90% of them are : return is_a($value, 'classname'); to change in : return $value instanceof classname; Or add the public static on static called method... E_STRICT error are added one by one when you increase php version, but some may be removed, the E_STRICT error are issue by zend parser if I remember well, then notice things that will not be supported in future. Anyway, on production box php should be configurer like that : report E_ALL display error false log error true E_STRICT error will not stop to works on the php 5.1.x tree, maybe in 5.2. but php6 will issue real error for that E_STRICT errors... On your dev box you should use latest version of php + have all previous one to pass the QA tests... Then it depend on your quality level needs and portability. (you can't certify a code to works on php5.0.0=>5.1.4, without testing ALL the vanilla versions AND all the distributions specific one) and I don't speak if you use things like apc that may issue strange error and so on. I think that maybe pear should be clear of the change between php4&5 compatible package and php5 only one. Maybe open http://pear2.php.net/ or move the not php5 E_STRICT one in http://oldpear.php.net ? ps : don't comply on a opensource project, if it don't fit your needs, simply makes a patch to have the thinks working like you wants... (and submit it to the php team to fix it) ps2 : we are in the same case as m$ API here, at the beginning, new installed box (with latest php) where two time the number of existing installation, now we have a slowering of new deployement, and people don't upgrade to avoid breaking something (squirrelmail that is still not php5 compliant for example) With php5 they introduced E_STRICT feature to solve the problem of upgrade and help people to know where they will be bugs in future... That's a good idea, but it don't works in the other side and I don't see why we need to kill php perf and spend time on a useless feature, people just have to upgrade (or trust their support to backport bugfix...)

Attachment: [application/pgp-signature]