Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98226
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <04295b76-3e0d-5ea3-7b4e-d07a15db4243@fleshgrinder.com>
References: <459c6bef-8936-634a-9520-dbd65c35b7c7@fleshgrinder.com>
 <CAF+90c9MWGkR3d9-vn-o_y_brs0XhOXapGD5cxq5r+v60pGVAg@mail.gmail.com> <04295b76-3e0d-5ea3-7b4e-d07a15db4243@fleshgrinder.com>
Date: Mon, 6 Feb 2017 22:26:32 +0100
Message-ID: <CABdc3WoV5y6_CVj-KMMGQy8KBaS9JhgttqPZv49Y7AymbvzP7A@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c12318c14e4340547e349b7
Subject: Re: [PHP-DEV] Namespaces in Core
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--94eb2c12318c14e4340547e349b7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Idea with PHP prefix is quite interesting, but as Nikita said only for PHP
related features.
There is one missing thing in those proposals.
Let's make PHP great again! Let it be `PHP\` prefix :)
To be camel or not to be? - solved!

2017-02-06 22:01 GMT+01:00 Fleshgrinder <php@fleshgrinder.com>:

> On 2/6/2017 9:47 PM, Nikita Popov wrote:
> > I'm strongly against use of the PHP namespace as a blanket namespace
> >  for bundled PHP extensions. The PHP namespace should be used only
> > for functionality that is actually in some way related to PHP. For
> > example, the php-ast extension could reasonably be namespaced as
> > php\ast, as it provides an AST for PHP specifically. Similarly the
> > tokenizer extension could reasonably be namespaced as php\tokenizer.
> >
> > Extensions which are not of this type should not live in the PHP
> > namespace, because they don't have anything specifically to do with
> > php, apart from the circumstance that they happen to be bundled at
> > the current point in time. Remember that extension may move from
> > being bundled to being in PECL and vice versa. If we decide to bundle
> > the MongoDB extension with php, would we rename the currently used
> > MongoDB namespace to PHP\MongoDB? If we decided to move it back to
> > PECL, would the namespace go back to just MongoDB? Or would it stay
> > PHP\MongoDB, despite not being part of PHP anymore? Should all new
> > extensions be written with a PHP namespace to account for the
> > possibility of the extension being bundled with PHP at a later point
> >  in time (even if there are no concrete plans to do so)?
> >
> > I would answer No to these questions. The namespace MongoDB is not,
> > as you say, "random", it is *meaningful*. The namespace PHP is (with
> >  the exceptions in the first paragraph notwithstanding) meaningless
> > and an artifact of the distribution mechanism, a mechanism which may
> >  change over time.
> >
> > Regards, Nikita
> >
>
> I thought about this too. I hope you understood that the main reasoning
> for me to choose a well known namespace prefix is related to
> auto-loading and when to trigger it. The lack of function and constant
> auto-loading is a pain and having well known prefixes could solve the
> issue since we would never require to even look at the auto-loader if
> the namespace starts with php.
>
> Obviously this could be solved for C extensions by allowing them to
> register another prefix that should not be auto-loaded: Sodium, MongoDB,
> ...
>
> Another solution could be to use pecl as their prefix. Although this
> couples it to the packaging system which might not be so nice.
>
> Any name that is tied to a company name or something else that makes
> things impossible for users to claim (Oracle, MongoDB, ...) is not a
> problem. In case of sodium that would probably be Paragon but Sodium
> might be fine too.
>
> I am not the judge here, the only thing I want is to ensure that this
> does not go unseen and that the potential of breaking something is real
> if we choose a random route like some others do. Not saying that we
> cannot do it, big ecosystems live without problems doing the same.
> However, it should be a very conscious choice and none that is taken
> lightly: meaning rules!
>
> --
> Richard "Fleshgrinder" Fussenegger
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
about.me/brzuchal
brzuchalski.com

--94eb2c12318c14e4340547e349b7--