On 29/11/12 18:17, Anthony Ferrara wrote: > Just pointing this out: that's NOT what this RFC recommends, and is > NOT what's being voted on. This RFC is talking about ONLY adding > E_DEPRECATED to core. And the way it's proposed to be done, the > "moves-to-PECL" couldn't happen, since it's hard-coded into the core > extension... > > So be careful what you're voting for... The RFC doesn't state if/when ext/mysql should be moved to pecl or if it should or not throw E_DEPRECATED there. It was stated in one of the previous threads that: - The extension would be moved to PECL when removed from core. - It's ok if you want to use ext/mysql from pecl as it's "unsupported" and your own problem, not one of php developers.
There were also concerns that throwing E_DEPRECATED didn't allow to cleanly use it (if you really wanted to) as if it was simply moved to pecl. I was presenting a way to throw E_DEPRECATED (assuming that option wins in the RFC) while also allowing an extension (typically hosted on PECL) to “provide” the non-E_DEPRECATED extension. If you take a closer look, you will see that it can happen, as long as the core deprecation is done in that way, anticipating usage of that pecl extension. (Note that it is a variable which could only be changed by another extension, I wasn't proposing the ini_set mentioned by Alan, IMHO that's an uglier solution, since everybody would end up setting it). You are of course welcome to point out any failures in the pseudo-code I presented. :) There would be a dependency on ELF-like binaries if using weak symbols. But the version removing ext/mysql will likely have a different ABI anyway, so it's not a big problem to require a recompile of pecl/mysql for the different php version. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
