Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91727
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.54 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <56E99E97.2050102@fleshgrinder.com>
References: <CAKws9z2e+GvX9gDJLPqTwio=Sr8i=0yQoCWVeyzvLh5Es24Kpg@mail.gmail.com>
 <CAGa2bXaQaBUi=C=MzhQYYznqRGJ06gR7oE+0nvuT6EKL6hN0gA@mail.gmail.com> <56E99E97.2050102@fleshgrinder.com>
Date: Thu, 17 Mar 2016 12:04:37 +0900
Message-ID: <CAGa2bXZYeTf7Hz5Doq+xf_vtM6=jxojx9SZb4gKMKaZKmvvMmQ@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Libsodium (bump)
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi all,

On Thu, Mar 17, 2016 at 2:57 AM, Fleshgrinder <php@fleshgrinder.com> wrote:
> On 3/15/2016 11:02 PM, Yasuo Ohgaki wrote:
>> Hi Scott,
>>
>> On Wed, Mar 16, 2016 at 2:40 AM, Scott Arciszewski <scott@paragonie.com> wrote:
>>> 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.

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