Re: [RFC] [VOTE] Libsodium as a core extension in PHP 7.2
| From: | Stephen Reay | 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