On Mon, Jan 28, 2013 at 4:32 PM, Lester Caine <les...@lsces.co.uk> wrote:
> Ferenc Kovacs wrote: > >> >But this is a core php feature, for anyone who does not use traits.... We >>> >use this quite a bit, it may not be for purists, but it has worked >>> >perfectly for years. This is getting a bit silly, change for change >>> sake.... >>> > >>> >> I've found this to be a huge wtf when you bump into, and already reported >> by E_STRICT, so I was sold to the arguments made in the RFC. >> > > I think that this is the point here ... > In order for legacy code to even work, E_STRICT has to be disabled, so one > does not see any problem. Please Lester, could you stop pretending that E_STRICT errors will crash your application and kill all the kittens? There are a bunch of people (myself included) who tries to write E_STRICT free code so that our application is fast and bugfree? Yes, there are people who ignore E_STRICT and E_DEPRECATED and I agree that having a zillion of those in the PEAR packages is a wrong thing. But currently it is the way to remove a feature: deprecate it both in the code and the manual, advertise in the release announcement, and remove it in the next version, hence people who are interested in keeping up with the changes will know what do they need to check and change. > That is the whole point of the switch? There is no requirement to test > code with the switch on, the wtf comes when something that is 'protected' > by E_STRICT is later removed! E_STRICT was introduced in 5.0 E_DEPRECATED was introduced in 5.3, E_STRICT was used for things that we use E_DEPRECATED now, but E_STRICT can be used stuff other than deprecating features (like suggesting better alternatives: http://lxr.php.net/xref/PHP_5_5/ext/date/php_date.c#1493 ) > This was one of the major rework areas on my own code and I can TOTALLY > understand people taking the ADVISED ROUTE of switching E_STRICT off as an > alternative solution. What do you mean by ADVISED ROUTE? I don't think we officially advised anybody for ignoring errors/warnings/etc. Maybe you mean that somebody from the php project advised you to ignore the E_STRICT messages in a 3rd party library that you are using and not wanting to clean up yourself? > NOW the question is, what is the point of E_STRICT if it can't be avoided > anyway? http://php.net/manual/en/errorfunc.constants.php "Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code." -- Ferenc Kovács @Tyr43l - http://tyrael.hu
