> "It's like our company car still works, but it no longer tighter meets > emissions > standards so they won't let us take it into the city any more"
That's a very interesting way to describe error level changes of a language. I wonder what happens when the manager asks - "What's with those guys who bought python/java trucks, go-carts? Do they also have these co2 problems?" Sorry for offtopic .. On a semi related note if the idea/discussion/RFC is for a betterment of language and future regarding warning/errors, it has always puzzled me: - why the engine is so minimalistic/unspecified regarding max_input_vars where the error is just "php-fpm: PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0" which isn't very helpful. Also is E_WARNING enough in this case since the variables are forcefully truncated? - and the second is memory_limit which again without any external tooling and/or debug mode while shows the file and line doesn't actually produce meaningful error/backtrace to indicate the problematic part (especially in production environments) We have patched the zend_alloc (in a rough way by searching through symbol_table for fastcgi params) to print more details at least in the fpm-sapi to be able to replicate the issue more easily, but then again I doubt it's the right way to do so.. While the second is hardly related (except the fact it's some sort of programming error condition) doesn't the first one need the same reclassification of error level as undefined variables? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
