On Tue, May 18, 2010 at 11:37 PM, Sara Golemon <poll...@php.net> wrote: >>> 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.
I misread this paragraph, I kept in mind what you said in your initial post: >> P.S. - Here's the signature I'd go with: openssl_encrypt($data, $method, >> $iv, $key, $raw=false) So yes, putting it at fifth optional argument can work as it won't change the behavior either. >> 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? Having new cleaner APIs is what I would prefer to do (in general). And we can indeed add the deprecated flag to 5.3 as well. 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
