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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
