Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99492
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.25.162 cause and error)
References: <990f6d85-e3ed-05a4-42e0-d3a279c0ebe7@fleshgrinder.com>
 <277f53cd-0e79-6fcc-fa4b-b0527ca525b6@fleshgrinder.com>
 <CAFMT4Nr1Git3u6oEBpZe4W3e68MnrOr6_bwAsRTzDtS2Y=Hbmg@mail.gmail.com>
 <3515b508-4571-0d57-6b47-616cae0b0908@fleshgrinder.com>
 <CA+kxMuQPoGrNEGQ9W0qD=ap=hx48AHXxhdtojyvZo9TuMz47_A@mail.gmail.com>
To: php-internals <internals@lists.php.net>,
 Dan Ackroyd <danack@basereality.com>
Message-ID: <f2a665ab-8001-b84f-f597-0797c625a8ad@fleshgrinder.com>
Date: Sun, 11 Jun 2017 09:14:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CA+kxMuQPoGrNEGQ9W0qD=ap=hx48AHXxhdtojyvZo9TuMz47_A@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="G7bWbdvcrAoaO8KXocdLL35imBRCOvp9N"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Namespaces in Core
From: php@fleshgrinder.com (Fleshgrinder)

--G7bWbdvcrAoaO8KXocdLL35imBRCOvp9N
Content-Type: multipart/mixed; boundary="2C3nnELaCNAujaFFu4SaGgAJxsp3ephR3";
 protected-headers="v1"
From: Fleshgrinder <php@fleshgrinder.com>
To: php-internals <internals@lists.php.net>,
 Dan Ackroyd <danack@basereality.com>
Message-ID: <f2a665ab-8001-b84f-f597-0797c625a8ad@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Namespaces in Core
References: <990f6d85-e3ed-05a4-42e0-d3a279c0ebe7@fleshgrinder.com>
 <277f53cd-0e79-6fcc-fa4b-b0527ca525b6@fleshgrinder.com>
 <CAFMT4Nr1Git3u6oEBpZe4W3e68MnrOr6_bwAsRTzDtS2Y=Hbmg@mail.gmail.com>
 <3515b508-4571-0d57-6b47-616cae0b0908@fleshgrinder.com>
 <CA+kxMuQPoGrNEGQ9W0qD=ap=hx48AHXxhdtojyvZo9TuMz47_A@mail.gmail.com>
In-Reply-To: <CA+kxMuQPoGrNEGQ9W0qD=ap=hx48AHXxhdtojyvZo9TuMz47_A@mail.gmail.com>

--2C3nnELaCNAujaFFu4SaGgAJxsp3ephR3
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 6/11/2017 1:08 AM, Dan Ackroyd wrote:
> Hi 'Fleshgrinder',
>=20
> I object to this RFC on principle.
>=20
> RFC's are supposed to be opionated. They are supposed to present an
> argument for why we should do something, and why doing that is a good
> idea.
>=20
> This RFC does not do that; it presents a series of questions to vote
> on, without any clear presentation of what problem they are solving or
> why people should be vote for the RFC.
>=20
> Asking people to vote on things like this, leads to choice being made
> at random, when there may not even be a need to make a choice in the
> first place.
>=20

> Introduce namespaces to user-level symbols to avoid collisions with
> user defined symbols, decrease breaking changes due to the
> introduction of new symbols and thus increase future compatibility.

On 6/11/2017 1:08 AM, Dan Ackroyd wrote:
> These parts of the RFC are particularly lacking justification:
>> Allow plural nouns in namespaces? Yes/No
>> Use namespace for the language itself (in the future)? Yes/No
>> Name of the language namespace? core/lang
>> Use namespace for tiny self-encapsulated things (in the future)? Yes/N=
o
>> Name of that namespace? std/util
>=20
> In addition, there are problems with other parts of the RFC.
>=20

> An important question to answer, if namespaces are to be used by PHP,
> is how they should be written. PHP has a long history of
> inconsistency, it therefore makes sense to define this upfront to
> ensure that any future effort is not going to introduce new
> inconsistencies.

> The vendor namespace itself does not contain any code directly, but
> instead is split into multiple sub-namespaces. This should ensure that
> we are not creating a new global namespace where everything that
> cannot be categorized ends up in.

> Std or util =E2=80=94 for tiny self-contained types (e.g.
> InvalidArgumentException) and functionality where it would be total
> overkill to create a dedicated namespace for (e.g. UUID).

On 6/11/2017 1:08 AM, Dan Ackroyd wrote:
>> Coding Standard? snake_case/PascalCase
> Shouldn't this be part of the other RFC?
>=20

> There are two possible choices:
>
> 1. snake_case
> 2. PascalCase (in accordance with class naming)
>
> Arguments for both approaches exist, however, it is after all a purely
> cosmetic question:

On 6/11/2017 1:08 AM, Dan Ackroyd wrote:
>> This could help to avoid those 1,000+ LOC files
> Splitting files to only contain related things is a good idea.
> Splitting related things into separate files, just because some
> arbitrary line limit has been reached, is not.
>=20

Splitting files to related things is exactly what this RFC is about.
Nowhere does it state that files must be split by a line limit.

On 6/11/2017 1:08 AM, Dan Ackroyd wrote:
>=20
> From the RFC:
>> Introduce namespaces to user-level symbols to avoid collisions with us=
er defined symbols
>>
>> Use namespace for the language itself (in the future)? Yes/No
>>
>=20
> From email, Fleshgrinder wrote:
>> I personally do not like this approach. PHP is the vendor of these
>> things, thus, it should reside in the namespace of the vendor. Same
>> rules for everyone.
>=20
> If this is actually problem, a better solution might be just reserve
> the global namespace in addition to the 'PHP' namespace. However the
> RFC does not say why it is a problem that needs addressing, and so we
> cannot explore possible solutions.
>=20

> Introduce namespaces to user-level symbols to avoid collisions with
> user defined symbols, decrease breaking changes due to the
> introduction of new symbols and thus increase future compatibility.

Reserving the global namespace now cannot achieve this, because it is
already in use by millions of projects out there.

On 6/11/2017 1:08 AM, Dan Ackroyd wrote:
> Multiple people have given you feedback that your idea of using a top
> level 'PHP' vendor namespace isn't a good match for the project.
> Rather than rephrasing what they have already said, I will just remind
> you of an earlier reply:
>=20
> From http://news.php.net/php.internals/98225
> 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.
>=20
> cheers
> Dan
> Ack
>=20

> Extensions which are provided by third-party vendors to the PHP Group
> for future maintenance and inclusion in the PHP repository go into
> their own vendor namespace. This should ensure that we can move those
> extensions to PECL without breaking compatibility on a namespace
> level.

--=20
Richard "Fleshgrinder" Fussenegger


--2C3nnELaCNAujaFFu4SaGgAJxsp3ephR3--

--G7bWbdvcrAoaO8KXocdLL35imBRCOvp9N
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZPO3hAAoJEOKkKcqFPVVrAEYP/3AIJokcy3M3ejZ+ChiV6SHN
Y6vLe5n2yo/Q2ECg8hotRj7yPgrhvjL9OjMlVAf3mAN44ZcLMa4yAH1WtytZtYt3
M9yHqMogBOBQQaNS7Lt3iNV8nLrnlc1Z05/RcBwbr5l7Fx479vxP1kHG7eiyhCms
iKju+oUgP7emNOZdf6XoP4yWMzLVTRFEKzJHdpfmxZiJTr717u9b3mhmjyu/c3vp
jLT8RAOn6iiNJDjpVX8BSShAZwyggkdKvuHuSbL3dojqeF2RLZaV5LbmKfE+XDoh
ZrCa85B0IIFki7v9RYN01MAez0gjvXk6PMgJfLbY6CCKpfsdJ6Bl3LwBSVNWN6dC
ExPrTrv/GnCdn1V+6oCpTOZjfoDOH3yj4fH3zLF8OxiRdtjm1f+Rh6Ji052Exx7t
MJEL8qWZuukX8rjTmi6hbsNRbgKAS5co1wSvdrsN7FDc1ehAkzy9T36algz01rwq
5fXTeS500Ys9RBnMQIetMSVoM72FcLSNeWZtjGvw6FiP2qHI1tXAXKun5kO6i5Qa
LVu5E7UTOfpSetR3ZbkHwSYVlLkM/O6EQari/Jj7jFfHt5CIcbuXXchDEq3XqBSh
kZC/qOLHg2QNSSNhLhRfWTdI7JG5/CwaJpKHhAoLK2OJ/WF7MbGcAgy7S5Vtm1sA
ue70NDhSl64lWEU/JBJ/
=8W8Z
-----END PGP SIGNATURE-----

--G7bWbdvcrAoaO8KXocdLL35imBRCOvp9N--