On Fri, Nov 30, 2012 at 12:57 AM, David Muir <davidkm...@gmail.com> wrote: > On 30/11/12 05:25, Ángel González wrote: >> 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. >> > > This is exactly why it doesn't make sense to have a vote on E_DEPRECATED > without understanding what the future action will be. > > I might have missed some as there was no summary of the discussion in > the RFC, or a summary of the various positions. This should have been > added before calling a vote. Combined with future action, the various > positions as I've read them are: > > 1. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and stop throwing > E_DEPRECATED > 2. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and continue > throwing E_DEPRECATED > 3. Move to PECL in 5.5 or 5.NEXT, and not throw E_DEPRECATED > 4. Throw E_DEPRECATED in 5.5. Remove from core and PECL in 5.NEXT > > #1 means it's not really being deprecated > #2 kind of makes sense, but then why even move it to PECL? > #3 is consistent with current release RFC process > #4 is the type of case E_DEPRECATED is meant to handle (or has handled > thus far)
It has been discussed to death. PECL provides superseded status, and leaving the flag untouched is rather logical. Can we stop this insane and repeatitve discussion and focus on having the flag or not? we have enough time to figure out which option fits best in the next release. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
