On Sat, Feb 4, 2017 at 5:37 AM, Fleshgrinder <p...@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