Re: [RFC] [VOTE] Libsodium as a core extension in PHP 7.2

From: Date: Sat, 04 Feb 2017 16:12:59 +0000
Subject: Re: [RFC] [VOTE] Libsodium as a core extension in PHP 7.2
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-98183@lists.php.net to get a copy of this message
Hi Scott, (Sorry for re-send) > On 4 Feb 2017, at 22:20, Scott Arciszewski <scott@paragonie.com> wrote: > > On Sat, Feb 4, 2017 at 5:37 AM, Fleshgrinder <php@fleshgrinder.com> wrote: >> >> On 2/4/2017 12:54 AM, Scott Arciszewski wrote: >>> I like \Sodium\foo instead of sodium_foo, but it deviates from the norm. >>> If we're going to break the norm, we should do so on a stronger majority >>> than 50%+1. >>> >> >> I see another problem besides the issue that a namespaced core elements >> are being introduced like in the US Senate, hidden within another bill, >> and the fact that I still don't like the Sodium API itself and that is >> that this might make autoloader updates in the future in regards to >> functions and/or constants more complicated. >> >> One idea back than was that the autoloader is only triggered for things >> that are listed in a use statement. This would have multiple advantages >> since we would not require any backslash in front of built-in stuff >> anymore as anything that is not within a use would never trigger the >> autoloader and remove any potential performance hit for built-in stuff >> due to autoloading. >> >> Sodium having its own namespace would definitely appear in use >> statements because that is how IDEs work today and because nobody wants >> to write Sodium\foo(), or do they? >> >> -- >> Richard "Fleshgrinder" Fussenegger > > Hi, > >> I see another problem besides the issue that a namespaced core elements >> are being introduced like in the US Senate, hidden within another bill, > > This is a separate choice that people can vote for. It's not exactly > hidden; nor is it bundled into a single "Yes/No". > > The vote option concerns "permit an exception to the coding style" not > "change the coding style for everything". If anyone playing at home > wants to propose a separate RFC to update the coding style to allow > the use of namespaced functions in all future RFCs, it looks like (at > present count) at least 7 people would find such a proposal amicable. > (8 if you count me, though I don't have vote karma so my opinion is > irrelevant.) > > Regards, > > Scott Arciszewski > Chief Development Officer > Paragon Initiative Enterprises <https://paragonie.com> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php I’m not a fan of the use of namespaced functions in the core either. Given that 2/3 is required to accept a change, wouldn’t it make more sense for the ‘default’ on Q2 be to follow PHP existing standards, and require the 2/3 majority to deviate from that? Cheers Stephen

« previous php.internals (#98183) next »