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)
The current release process RFC states:
*
*x.y.z to x.y+1.z*
o
Bugfixes
o
New features
o
*Extensions support can be ended (moved to pecl)*
o
Backward compatibility must be kept
o
API compatibility must be kept (userland)
o
ABI and API can be broken (internals), src compatibility
should be kept if possible, while breakages are allowed
[emphasis mine]
Some are saying that that E_DEPRECATED can/should be used for entire
extensions. That's fine and dandy if said extension is actually going to
be removed (not just retired to PECL, but dropped completely), but
somehow I think a lot more people would object to the current RFC if
that were the plan.
Cheers,
David
