# [RFC] [VOTE] Libsodium as a core extension in PHP 7.2 - Thread: https://externals.io/message/98146 - Original archive: https://news-web.php.net/php.internals/98146 - Started by Scott Arciszewski on 2017-02-03T20:44:55+00:00 - Messages: 13 - RFC: Libsodium (Implemented (PHP 7.2)) — https://externals.io/rfc/libsodium.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #98146 — Scott Arciszewski — 2017-02-03T20:44:55+00:00 URL: https://externals.io/message/98146#98146 I've opened the vote for the libsodium RFC. https://wiki.php.net/rfc/libsodium See https://externals.io/thread/626 for the previous discussion topics. The vote closes at 21:00 UTC (4 PM Eastern Time) next Friday. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises wrote: > I've opened the vote for the libsodium RFC. > > https://wiki.php.net/rfc/libsodium > > See https://externals.io/thread/626 for the previous discussion topics. > > The vote closes at 21:00 UTC (4 PM Eastern Time) next Friday. > I voted for "No, sodium_foo" syntax in order to be consistent with existing procedural APIs. 2/3 majority wouldn't fit nicely. What it would be if vote result is 51% vs 49%? More than half is good enough for 2nd vote choice. IMO. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #98155 — Scott Arciszewski — 2017-02-03T23:54:29+00:00 URL: https://externals.io/message/98146#98155 · In reply to: #98153 > Hi Scott and all, > > On Sat, Feb 4, 2017 at 5:44 AM, Scott Arciszewski > wrote: > > > […] > > I voted for "No, sodium_foo" syntax in order to be consistent with > existing procedural APIs. > 2/3 majority wouldn't fit nicely. What it would be if vote result is 51% > vs 49%? > More than half is good enough for 2nd vote choice. IMO. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > > 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. Also, I thought the rules changed so *_everything_* needed 2/3 now?​ ​ Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises ​ --- ## #98158 — Nikita Popov — 2017-02-04T00:04:32+00:00 URL: https://externals.io/message/98146#98158 · In reply to: #98155 On Sat, Feb 4, 2017 at 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. > > Also, I thought the rules changed so *_everything_* needed 2/3 now?​ > The usual rule is that "secondary" votes use 50% majority, to avoid bias in one direction or the other. Regards, Nikita --- ## #98161 — Alex Bowers — 2017-02-04T01:22:54+00:00 URL: https://externals.io/message/98146#98161 · In reply to: #98158 > On Sat, Feb 4, 2017 at 12:54 AM, Scott Arciszewski > wrote: > > > […] > topics. > > […] > 51% > > […] > majority > > […] > > The usual rule is that "secondary" votes use 50% majority, to avoid bias in > one direction or the other. > > Regards, > Nikita > Would it not be possible for _both_ to be supported? It would be just an alias --- ## #98166 — Yasuo Ohgaki — 2017-02-04T05:24:31+00:00 URL: https://externals.io/message/98146#98166 · In reply to: #98161 > Would it not be possible for _both_ to be supported? It would be just an > alias I would vote for this!! Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #98174 — Niklas Keller — 2017-02-04T09:17:47+00:00 URL: https://externals.io/message/98146#98174 · In reply to: #98161 > > Would it not be possible for _both_ to be supported? It would be just an > alias > What's the benefit? I can just see bloat and confusion. --- ## #98176 — Fleshgrinder — 2017-02-04T10:37:09+00:00 URL: https://externals.io/message/98146#98176 · In reply to: #98155 > 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 --- ## #98178 — Scott Arciszewski — 2017-02-04T15:20:45+00:00 URL: https://externals.io/message/98146#98178 · In reply to: #98176 > > > > […] > > 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 Hi, > > 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 > Hey :) Oh don't get me wrong here, I have no problem with namespaced core stuff in general and I'd probably vote yes myself. The issue here is that it might (!) be that some of the people who actually can vote do not participate in the vote because they think "oh well, sodium sounds like an RFC I'm not interested in I'll let the others vote" and in reality the results change a thing that was the same since the inception of PHP. This is what I wanted to express with the comparison to the US Senate. ;) -- Richard "Fleshgrinder" Fussenegger --- ## #98183 — Stephen Reay — 2017-02-04T16:12:59+00:00 URL: https://externals.io/message/98146#98183 · In reply to: #98178 Hi Scott, (Sorry for re-send) > > > > > […] > > Hi, > > > […] > > 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 > > -- > > 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 --- ## #98184 — Nikita Popov — 2017-02-04T16:16:06+00:00 URL: https://externals.io/message/98146#98184 · In reply to: #98146 On Fri, Feb 3, 2017 at 9:44 PM, Scott Arciszewski wrote: > I've opened the vote for the libsodium RFC. > > https://wiki.php.net/rfc/libsodium > > See https://externals.io/thread/626 for the previous discussion topics. > > The vote closes at 21:00 UTC (4 PM Eastern Time) next Friday. > I just took a very quick look at the extension source. One question: Right now it throws recoverable fatal errors all over the place. Why doesn't it use exceptions instead? We replaced (to the most part) use of recoverable fatals with exceptions in PHP 7 and reintroducing them in this quantity would be highly dubious to me. Also a question on maintenance: If this extension is bundled, will the source compatibility with PHP 5 be removed, or do you plan on keeping a single code-base for the bundled extension and PECL, with support for PHP 5? None of the current bundled extensions do this, as it is a significant maintenance burden. Thanks, Nikita --- ## #98187 — Scott Arciszewski — 2017-02-04T16:23:33+00:00 URL: https://externals.io/message/98146#98187 · In reply to: #98184 > On Fri, Feb 3, 2017 at 9:44 PM, Scott Arciszewski > wrote: > > […] > > > I just took a very quick look at the extension source. One question: Right > now it throws recoverable fatal errors all over the place. Why doesn't it > use exceptions instead? We replaced (to the most part) use of recoverable > fatals with exceptions in PHP 7 and reintroducing them in this quantity > would be highly dubious to me. > > Also a question on maintenance: If this extension is bundled, will the > source compatibility with PHP 5 be removed, or do you plan on keeping a > single code-base for the bundled extension and PECL, with support for PHP 5? > None of the current bundled extensions do this, as it is a significant > maintenance burden. > > Thanks, > Nikita Hi Nikita, > I just took a very quick look at the extension source. One question: Right > now it throws recoverable fatal errors all over the place. Why doesn't it > use exceptions instead? We replaced (to the most part) use of recoverable > fatals with exceptions in PHP 7 and reintroducing them in this quantity > would be highly dubious to me. I don't know why it doesn't (my guess: that part of the code simply wasn't updated); but if we include libsodium in 7.2, I'd definitely switch everything to use exceptions instead of fatal errors, for exactly the same reasons laid out in the discussion over random_* throwing exceptions in 7.0. > Also a question on maintenance: If this extension is bundled, will the > source compatibility with PHP 5 be removed, or do you plan on keeping a > single code-base for the bundled extension and PECL, with support for PHP 5? > None of the current bundled extensions do this, as it is a significant > maintenance burden. Definitely drop PHP 5 support in the extension that is bundled with PHP 7.2 (although the PECL extension can keep it), Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises