Hey Scott, On 1 June 2016 at 09:49, Scott Arciszewski <sc...@paragonie.com> wrote:
> Hi PHP Internals Team, > > Let's begin discussing the prospect of adding libsodium as a core extension > in PHP 7.1. I've updated the RFC to explain why this would be a good idea > and the benefits it offers. > > https://wiki.php.net/rfc/libsodium > > If the subsequent discussion goes smoothly, I would like to open voting on > June 15. > > Together, let's make PHP cryptography so safe that it becomes boring. > First, thanks for providing better alternatives to crypto in PHP! I also agree with Remi on naming: let's avoid calling the extension `libsodium`. I have some concerns that are just about code quality, not about functionality. Consider that I didn't look at the underlying library (and I really care little about it, from a consumer perspective). 1. is there a particular reason why abbreviations are used? For instance, why `sodium_randombytes_buf()` instead of `sodium_random_bytes_buffer()`? 2. from a naming perspective, I'd expect `sodium_randombytes_buf()` to give me a buffer of random bytes (probably as a stream), but it returns the actual string of random bytes. Again: confusing naming 3. can we avoid using "themed" naming? For example, instead of `sodium_crypto_secretbox()`, it would be best to express what it actually does, like `sodium_encrypt_and_sign()`. While the naming may be emerging from lower layers, I still (like I did with other RFCs) disagree with inheriting confusing naming. This will just cause users to look up the naming up when reading or writing code, and ultimately add up to silly bugs. I can already foresee that people will use the API incorrectly just because of the naming. 4. can't we just keep it namespaced under `Sodium`, instead of adding more stuff to the root level namespace? Does anyone have a reference to the coding standards that would cause the rename? Cheers, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
