Pierre, > I am all for having it in hash as well. But yes, it requires more work > that may need additional RFC (changing the API to allow more options > need discussions).
What options are needed? The API refactoring that I have done has all been to static functions, and extracting methods from public ones. I didn't need to change any public APIs (that I saw). I'm not sure what "more options" intended to mean (by you, or by Scott), but I don't see the need, as it's implemented and passes tests without that. If I'm missing something, please let me know. I'm not arguing that it doesn't need an RFC, just trying to clarify the API change. The only API change would be the addition of the method (at least based on my implementation)... So if it still needs an RFC, I'm fine with that. I'll whip one up for mine after I get the PR tested (I have it applied successfully, just want to verify it a few more times by re-compiling a few times before submitting the PR and writing the RFC): https://github.com/ircmaxell/php-src/tree/hash_pbkdf2 > That being said, I am really not in favor of having it yet in 5.4. For > two reasons, first 5.4 is bugs fixes only, no new feature. The second > reason is the whole thing behind this addition. As it looks self > contained, I am not convinced that it is a good choice, or that it is > well tested or designed (api wised) yet. I would prefer to leave it > master for now and see if it is usable and stable for php-next. I have > to ask to revert this addition in the 5.4 branch. No argument there at all. While it would be nice to get it in 5.4, I can certainly live with 5.5. Especially with the more rapid release cycles that have been occurring here (instead of 3 to 4 years between releases). Thanks! Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
