Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98220
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 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: Mon, 6 Feb 2017 19:50:24 +0000
Message-ID: <CAPg3XxLyQ-aHOXCczOxBDGAN+MBRzGfRu0fm=2cjv_C=mx7_Yg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113b0a50a4319d0547e1f33e
Subject: Re: [PHP-DEV] Namespaces in Core
From: petercowburn@gmail.com (Peter Cowburn)

--001a113b0a50a4319d0547e1f33e
Content-Type: text/plain; charset=UTF-8

On 6 February 2017 at 17:21, 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.
>

I don't often chime in on the internals list, so please excuse this
interruption.  Slinking in a vote which essentially is about adopting
namespaces in core, via new library RFC, is not the way to go about
changing our coding standards.  In short, I don't want to the see the
situation where this extension gets merged in to 7.2 (which it should be
:)) only to have someone ask, "what about the 'php' top-level namespace?"
and we all shrug and mutter, "too late" under our breaths.


>
> 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 today.
>
> [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 concerns.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a113b0a50a4319d0547e1f33e--