Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98248
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain paragonie.com designates 74.125.82.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <459c6bef-8936-634a-9520-dbd65c35b7c7@fleshgrinder.com>
References: <459c6bef-8936-634a-9520-dbd65c35b7c7@fleshgrinder.com>
Date: Tue, 7 Feb 2017 12:56:46 -0500
Message-ID: <CAKws9z0a1uD2qmiWoOiN_HbftMzKROFijtzC3P1zwrS0XxvCaQ@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c192216bd584a0547f4787e
Subject: Re: [PHP-DEV] Namespaces in Core
From: scott@paragonie.com (Scott Arciszewski)

--94eb2c192216bd584a0547f4787e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder <php@fleshgrinder.com> wrote:

> Hey guys! :)
>
> First: I like namespaces in Core but here me out!
>
> https://wiki.php.net/rfc/libsodium
>
> The second vote is clearly going to be that this new feature is added to
> the core with a namespace. I already complained about this but it seems
> to go unnoticed or others do not see the potential problems that might
> be introduced by this.
>
> Sodium (or insert possible future namespace in Core here) might be a
> valid username and existing community standards use the first namespace
> for the vendor. Using those first level vendor namespaces in Core always
> comes a long with a potential problem for users with that name.
>
> The PHP (case does not matter) would be the proper vendor name to put
> Core stuff in, as far as I remember it is also reserved for PHP
> functionality. There were also numerous discussions about providing a
> cleaned up API there while maintaining backwards compatibility via
> aliases and so forth in the non-namespaced Core stuff.
>
> Using the PHP vendor name as first level namespace would defeat problems
> with userland namespaces and be a much safer choice. Hence,
> `php\sodium`/`PHP\Sodium`/`Php\Sodium` would be the clear choice.
>
> There is another issue regarding auto-loading. If we randomly introduce
> first-level namespaces we de facto make it much harder for us to exclude
> some pattern from the auto-loader. However, putting everything Core
> related into `Php` would mean that we can always sidestep any
> auto-loader calls since we know up front that this must be a C thing.
>
> Most package and/or namespace system do that to avoid problems with
> their users:
>
> - Java: `java*`
> - C#: `System*`
> - C++: `::std*`
> - Rust: `core::*` and `std::*` [1]
> - Scala: `scala*`
> - Kotlin: `kotlin*`
> - Ceylon: `ceylon*`
> - ...
>
> Obviously there are some counter examples too:
>
> - Go: random
> - Python: random
> - Javascript: random
> - ...
>
> But at least they go through an extensive standardization process where
> the names are being discussed ad infinitum to ensure that they are super
> generic and thus useful. It is very unlikely that `IO` or `OS` collides
> with a username.
>
> I personally would love to see namespaces but I definitely do not want
> to see random namespaces. I hope we are not going down a road that is
> hard to repair later, like with so many other things we have in Core toda=
y.
>
> [1] Rust decided against vendor names for some reasons they explained
> once in a blog post. I believe that this will become a problem for them
> at some point in time since coming up with nice names over time for
> users is very hard. We'll see if Rust persists and invalidates my concern=
s.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
=E2=80=8BHi,
=E2=80=8B

> - Java: `java*`
> - C#: `System*`
> - C++: `::std*`
> - Rust: `core::*` and `std::*` [1]
> - Scala: `scala*`
> - Kotlin: `kotlin*`
> - Ceylon: `ceylon*`
> - ...



I=E2=80=8B would definitely like to see something like this land in 7.2:

$plaintext =3D \Std\Sodium\box_open($ciphertext, $key, $nonce);

Is everyone willing to allow the coding standard to be updated at all,
though? I'm taking all the No votes spawned by this thread to mean "we
don't want namespaced functions ever".

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
=E2=80=8B

--94eb2c192216bd584a0547f4787e--