Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99490
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 74.125.83.46 cause and error)
MIME-Version: 1.0
In-Reply-To: <3515b508-4571-0d57-6b47-616cae0b0908@fleshgrinder.com>
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>
Date: Sun, 11 Jun 2017 00:08:50 +0100
Message-ID: <CA+kxMuQPoGrNEGQ9W0qD=ap=hx48AHXxhdtojyvZo9TuMz47_A@mail.gmail.com>
To: Fleshgrinder <php@fleshgrinder.com>
Cc: php-internals <internals@lists.php.net>, Levi Morrison <levim@php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Namespaces in Core
From: danack@basereality.com (Dan Ackroyd)

Hi 'Fleshgrinder',

I object to this RFC on principle.

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.

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.

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.

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/No
> Name of that namespace? std/util

In addition, there are problems with other parts of the RFC.

> Coding Standard? snake_case/PascalCase
Shouldn't this be part of the other RFC?

> 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.


From the RFC:
> Introduce namespaces to user-level symbols to avoid collisions with user defined symbols
>
> Use namespace for the language itself (in the future)? Yes/No
>

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.

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.

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:

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.

cheers
Dan
Ack