I don't think that's a good idea. There are already production systems that call it like \Sodium::function_here().
I'm not an extension developer; I don't know what level of effort would even be required to refactor it from a class with static methods to a namespace with functions. And when you consider the amount of effort you're asking the developers who are already using the existing method, it doesn't seem worth it anyway. What is your reason for wanting to change Sodium to a namespace and all methods to functions? Especially as someone who, presumably, has never used the library before. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com> On Fri, May 22, 2015 at 2:26 AM, Michael Wallner <m...@php.net> wrote: > On 21/05/15 09:49, Peter Petermann wrote: > > Hi Scott, > > > > I personally think the RFC is a bit short, > > also I just had a very brief look at the documentation of the > extension in > > question, and find its API a bit strange, > > whats up with having everything in static method calls? > > > > regards, > > PP > > > > 2015-05-21 3:15 GMT+02:00 Scott Arciszewski <sc...@paragonie.com>: > > > >> The current state of cryptography in PHP is, well, abysmal. Our two main > >> choices for handling symmetric cryptography are libmcrypt (collecting > dust > >> since 2007) and openssl, which lacks a streaming API (e.g. > mcrypt_generic) > >> and GCM support. > >> > >> > >> I think now is a good time to talk about the possibility of making > >> libsodium a core PHP extension, depending on where things are when we > near > >> the 7.1 feature freeze. > >> > >> I've just opened an RFC for precisely this purpose: > >> https://wiki.php.net/rfc/libsodium > >> > > Yes, the choice of API looks pretty awkward; if we could settle on > PHP-5.6+, change Sodium to a namespace and all methods to functions > therein. > > -- > Regards, > Mike > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
