Link to RFC: https://wiki.php.net/rfc/libsodium
I'd like to bump the RFC to make Libsodium a core extension, as per
Ferenc's suggestion on the mcrypt RFC.
Question: If this extension is adopted, which syntax would you prefer?
\Sodium\func()
Sodium::func()
sodium_func()
As it currently stands, the PHP extension in PECL uses a namespace +
function format.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com
Link to RFC: https://wiki.php.net/rfc/libsodium
I'd like to bump the RFC to make Libsodium a core extension, as per
Ferenc's suggestion on the mcrypt RFC.Question: If this extension is adopted, which syntax would you prefer?
\Sodium\func() Sodium::func() sodium_func()As it currently stands, the PHP extension in PECL uses a namespace +
function format.Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com
The third option (sodium_func()) as per coding standard:
https://github.com/php/php-src/blob/master/CODING_STANDARDS#L110-L125
I do not think that it makes sense to provide a static class for this
functionality, correct me if I am wrong.
It definitely makes no sense to namespace the stuff if you want it in
core and it violate the coding standards (for a good reason).
--
Richard "Fleshgrinder" Fussenegger
Link to RFC: https://wiki.php.net/rfc/libsodium
I'd like to bump the RFC to make Libsodium a core extension, as per
Ferenc's suggestion on the mcrypt RFC.Question: If this extension is adopted, which syntax would you prefer?
\Sodium\func() Sodium::func() sodium_func()As it currently stands, the PHP extension in PECL uses a namespace +
function format.Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comThe third option (sodium_func()) as per coding standard:
https://github.com/php/php-src/blob/master/CODING_STANDARDS#L110-L125
I do not think that it makes sense to provide a static class for this
functionality, correct me if I am wrong.It definitely makes no sense to namespace the stuff if you want it in
core and it violate the coding standards (for a good reason).--
Richard "Fleshgrinder" Fussenegger
Okay, I missed that detail somehow.
I talked with Frank and the current plan of action as I understand it is:
- Finish libsodium 1.0.9
- Finish libsodium-php 1.0.3
- Create a branch for this RFC that conforms to the coding standards
- If the RFC passes, send a pull request to add the standards-conforming
version of the sodium PHP extension to core
I'll hold off on opening the vote until there's something concrete and
meaningful for everyone to test.
Are there any other concerns, questions, comments, etc. that haven't
already been addressed in the previous thread?
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
Hi Scott,
Question: If this extension is adopted, which syntax would you prefer?
\Sodium\func() Sodium::func() sodium_func()
I prefer both of
Sodium::func()
sodium_func()
IMO, we are better to provide both OO and procedural API which have
identical features. i.e. I prefer multi paradigm programming language.
It would be natural for PHP since PHP was born as procedural language
and evolving as OO.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Scott,
Question: If this extension is adopted, which syntax would you prefer?
\Sodium\func() Sodium::func() sodium_func()I prefer both of
Sodium::func() sodium_func()IMO, we are better to provide both OO and procedural API which have
identical features. i.e. I prefer multi paradigm programming language.
It would be natural for PHP since PHP was born as procedural language
and evolving as OO.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Providing both only makes sense if you receive an object on which you
can perform more operations. It is a different situation if everything
that the extension provides is always a function in a mathematical sense
(same input produces single output). I love multi-paradigm languages but
that does not mean that everything needs to provide every paradigm; you
actually end up with a mess in such cases. We have good examples where
it makes sense [1] and bad examples where it makes no sense [2] together
in a single extension. The major reason to provide an object is to
encapsulate some information and/or state that you can pass around
(dependency injection) and that has some kind of behavior. This is most
certainly not the case in [2] because it consists only of previously
mentioned mathematical functions. [1] is different, it can be passed
around, preconfigured with some state (a specific locale and pattern).
It would become even more useful if one could instantiate it only with a
locale and pass it around, prepared to handle multiple patterns; but
that's another story.
[1] https://secure.php.net/class.messageformatter
[2] https://secure.php.net/class.locale
TL;DR Providing Ext::fn() and ext_fn() for everything only creates a
mess. Decide on one way and decide on the way that makes sense.
Multi-paradigm does not mean "provide/use everything, always" it means
"provide/use one paradigm as it make senses from multiple ones"; that is
also where it takes its strength from.
--
Richard "Fleshgrinder" Fussenegger
Hi all,
Hi Scott,
Question: If this extension is adopted, which syntax would you prefer?
\Sodium\func() Sodium::func() sodium_func()I prefer both of
Sodium::func() sodium_func()IMO, we are better to provide both OO and procedural API which have
identical features. i.e. I prefer multi paradigm programming language.
It would be natural for PHP since PHP was born as procedural language
and evolving as OO.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.netProviding both only makes sense if you receive an object on which you
can perform more operations. It is a different situation if everything
that the extension provides is always a function in a mathematical sense
(same input produces single output). I love multi-paradigm languages but
that does not mean that everything needs to provide every paradigm; you
actually end up with a mess in such cases. We have good examples where
it makes sense [1] and bad examples where it makes no sense [2] together
in a single extension. The major reason to provide an object is to
encapsulate some information and/or state that you can pass around
(dependency injection) and that has some kind of behavior. This is most
certainly not the case in [2] because it consists only of previously
mentioned mathematical functions. [1] is different, it can be passed
around, preconfigured with some state (a specific locale and pattern).
It would become even more useful if one could instantiate it only with a
locale and pass it around, prepared to handle multiple patterns; but
that's another story.[1] https://secure.php.net/class.messageformatter
[2] https://secure.php.net/class.localeTL;DR Providing Ext::fn() and ext_fn() for everything only creates a
mess. Decide on one way and decide on the way that makes sense.
Multi-paradigm does not mean "provide/use everything, always" it means
"provide/use one paradigm as it make senses from multiple ones"; that is
also where it takes its strength from.
Sounds good to me, too. We may consider more carefully. Current
namespaced names may be the best option.
The only problem with this is "It looks inconsistent with existing
module functions". We may consider how we are going to use namespaces
for extensions in general. I like the idea
\ModuleName\function_name
for all extension functions, indeed.
Question is whether we should use something like
"\PHP\ModuleName\function_name" or "\ModuleName\function_name". I'm
not sure which one is better in the long run.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
The only problem with this is "It looks inconsistent with existing
module functions". We may consider how we are going to use namespaces
for extensions in general. I like the idea\ModuleName\function_name
for all extension functions, indeed.
Question is whether we should use something like
"\PHP\ModuleName\function_name" or "\ModuleName\function_name". I'm
not sure which one is better in the long run.
I think that this is not necessary. The existing system does not seem to
pose any problems, changing the coding standard now only creates a
mixture. There are still many extension who are not even in conformance
with the coding standard and such a change would make it even worse.
Let's first try to clean things up; which is already a super hard task
because many people are completely against, as we've seen it in the
var deprecation thread.
That being said, \PHP\ModuleName\function_name is a very bad choice
for multiple reasons:
- PHP already has its reserved namespace, the global one **.
- Is it \PHP or \Php? This opens a huge can of worms.
And even if it is \ModuleName\function_name:
- The amount of use statements will explode and the situation becomes
equal to the one we had in the past with the millions of
require(_once) lines in the preamble of each file. It requires more
management on the userland side.
TL;DR the current system works just fine so why change? Just because it
is sexy right now? Will it be sexy in 10 years?
--
Richard "Fleshgrinder" Fussenegger
- PHP already has its reserved namespace, the global one **.
- Is it \PHP or \Php? This opens a huge can of worms.
We've technically only reserved PHP and php but it is case insensitive
anyway. PHP does not reserve the global namespace. At least that's
not what it says in the docs.
At least that's not what it says in the docs.
I meant: at least according to the docs:
http://php.net/manual/en/language.namespaces.rationale.php
Namespace names PHP and php, and compound names starting with these names (like PHP\Classes) are reserved for internal language use and should not be used in the userspace code.
At least that's not what it says in the docs.
I meant: at least according to the docs:
http://php.net/manual/en/language.namespaces.rationale.phpNamespace names PHP and php, and compound names starting with these names (like PHP\Classes) are reserved for internal language use and should not be used in the userspace code.
Okay, I did not know that. However, right now all internal classes and
functions are in ** and that is also what the coding standards
prescribe. My point being (and was) that this system works well, so why
change it now shortly after a new major version. Changing all old code
would result in an unbelievable breaking change, even with a new major
version, without any real value. Yes, I am saying that although I am
usually totally in favor of changing things to the better. I simply do
not see any benefit here.
--
Richard "Fleshgrinder" Fussenegger
At least that's not what it says in the docs.
I meant: at least according to the docs:
http://php.net/manual/en/language.namespaces.rationale.phpNamespace names PHP and php, and compound names starting with these
names (like PHP\Classes) are reserved for internal language use and should
not be used in the userspace code.Okay, I did not know that. However, right now all internal classes and
functions are in ** and that is also what the coding standards
prescribe. My point being (and was) that this system works well, so why
change it now shortly after a new major version. Changing all old code
would result in an unbelievable breaking change, even with a new major
version, without any real value. Yes, I am saying that although I am
usually totally in favor of changing things to the better. I simply do
not see any benefit here.--
Richard "Fleshgrinder" Fussenegger
I'm 99% sure that the plan is to go with sodium_* since the change isn't
/that/ painful. (Creating a polyfill for code written against the PHP
extension is trivial.)
While I'd love to break new ground with this (the first extension to
actually use the reserved namespace), I'm concerned this would just create
a lot of pointless bikeshedding arguments. The goal here isn't to be
totally avant garde and break exciting new ground (even if the plot is
already allocated for "future development").
The goal here (for me, anyway) is to make cryptography in PHP boring: It
should be simply secure (with a security level >= 2^100 bits for all
meaningful metrics), as side-channel resistant as possible, and intuitive
for non-cryptographers to use properly. I want to see PHP get to where it's
easier to do the secure thing than to do the insecure thing. The password
hashing API in 5.5 was the first great leap towards this goal. Adding
CSPRNG functions in PHP 7 that throws an Exception when PHP can't access
the kernel's CSPRNG moved us further in the right direction.
Deprecating libmcrypt and introducing libsodium is, to me, the next logical
step towards that goal.
Until that happens, PHP developers will be given more than enough rope to
hang themselves (and the company they work for) with their fumbled
cryptography engineering. Let's take away the noose and give everyone a
safety net.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
Hi Levi,
At least that's not what it says in the docs.
I meant: at least according to the docs:
http://php.net/manual/en/language.namespaces.rationale.phpNamespace names PHP and php, and compound names starting with these names (like PHP\Classes) are reserved for internal language use and should not be used in the userspace code.
Question would be "When and How we are going to use it?"
Putting everything under \PHP namespace would be nice in general. We
can provide compatible APIs under \PHP. e.g. \PHP\7_0 may be PHP 7.0
compatible APIs for PHP 8.0, etc. It makes upgrading and version up
easier if this is done.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I think I've said this before; please call it ext-sodium, not ext-libsodium.
David
Link to RFC: https://wiki.php.net/rfc/libsodium
I'd like to bump the RFC to make Libsodium a core extension, as per
Ferenc's suggestion on the mcrypt RFC.Question: If this extension is adopted, which syntax would you prefer?
\Sodium\func()
Sodium::func()
sodium_func()As it currently stands, the PHP extension in PECL uses a namespace +
function format.Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com
Noted and agreed.
I think I've said this before; please call it ext-sodium, not
ext-libsodium.David
Link to RFC: https://wiki.php.net/rfc/libsodium
I'd like to bump the RFC to make Libsodium a core extension, as per
Ferenc's suggestion on the mcrypt RFC.Question: If this extension is adopted, which syntax would you prefer?
\Sodium\func()
Sodium::func()
sodium_func()As it currently stands, the PHP extension in PECL uses a namespace +
function format.Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com