The only BC break is the warning raised when using openssl_encrypt() without
an IV. Given the extremely bad practice using a NULL IV represents, I think
this is a reasonable course of action.
It changes the signature making the fifth argument a complete
different thing. I strongly disagree with this strategy, even if I can
understand your reasoning. We can't begin to "fix" things by changing
existing API signatures, that's going to end badly.
What do you mean by "making the fifth argument a complete different thing"? Different to what? The current signature only has four arguments. This adds an optional argument which, by itself, is not BC breaking.
If you really feel strongly about it, I can add it as a new function entirely, but the duplication seems very unnecessary to me.
I'm all for preserving BC, but when one does so at the sacrifice of reason* it just makes us all look a bit silly.
To define a new and clean API is not only BC but may also allow
obvious naming. And last but not least, it can then be merged in 5.3
without worrying about any possible impact.
Absolutely true, and /possibly/ worth the "wtf" that comes with having two essentially identical functions. How would you feel about the trunk versions of the old functions (but not the 5.3 versions) gaining ZEND_ACC_DEPRECATED in that case?
-Sara
* Once again, the current 5.3 implementation is worthless, it is without worth, it has no value of any worth, it's worthless Dave.