Hi! > My thought that @ mainly relates to another RFC where errors/warning > are very inconsistently reported or designed (like forcing one to use > @). 8 would be a good candidate to clean that up, like the TypeError > RFC.
Cleaning up how PHP does errors would be awesome. After 20+ years of organic growth without clear standards in this area, we've got a lot of messy stuff happening there. But I don't think it can solve any immediate issues - it's not likely that we'll replace every warning in every extension overnight. It'd be nice if we found some model that miraculously plugs into existing one and allows to improve things while keeping everything working. If we get good new APIs - fine, but we'll need @ to work with old APIs for a while. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
