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 <https://paragonie.com
Hi Scott and all,
On Sat, Feb 4, 2017 at 5:44 AM, Scott Arciszewski scott@paragonie.com
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
Hi Scott and all,
On Sat, Feb 4, 2017 at 5:44 AM, Scott Arciszewski scott@paragonie.com
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
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 https://paragonie.com/
On Sat, Feb 4, 2017 at 12:54 AM, Scott Arciszewski scott@paragonie.com
wrote:
Hi Scott and all,
On Sat, Feb 4, 2017 at 5:44 AM, Scott Arciszewski scott@paragonie.com
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.netI 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
On Sat, Feb 4, 2017 at 12:54 AM, Scott Arciszewski scott@paragonie.com
wrote:Hi Scott and all,
On Sat, Feb 4, 2017 at 5:44 AM, Scott Arciszewski <scott@paragonie.com
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.netI 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
Would it not be possible for both to be supported? It would be just an
alias
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
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.
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
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 writeSodium\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
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 https://paragonie.com
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
Hi Scott,
(Sorry for re-send)
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 writeSodium\foo(), or do they?--
Richard "Fleshgrinder" FusseneggerHi,
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--
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
On Fri, Feb 3, 2017 at 9:44 PM, Scott Arciszewski scott@paragonie.com
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
On Fri, Feb 3, 2017 at 9:44 PM, Scott Arciszewski scott@paragonie.com
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
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 <https://paragonie.com