Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109716
MIME-Version: 1.0
References: <CABdc3WoTeO4eTAoHCfqKyy8PWjrn97w9JXXhD88c3O9xPzp7QQ@mail.gmail.com>
In-Reply-To: <CABdc3WoTeO4eTAoHCfqKyy8PWjrn97w9JXXhD88c3O9xPzp7QQ@mail.gmail.com>
Date: Mon, 20 Apr 2020 14:06:46 +0200
Message-ID: <CAEPJdukDAbNSjtS=VdjaMmUtA1fwN0eJ=EXKziTs3dgWUWZ4Rw@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal.brzuchalski@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000051ffcc05a3b7bc3b"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core
From: kontakt@beberlei.de (Benjamin Eberlei)

--00000000000051ffcc05a3b7bc3b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Micha=C5=82, George,

On Wed, Apr 15, 2020 at 2:29 PM Micha=C5=82 Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

> Hi internals,
>
> I hope you're doing well.
>
> I'd like to announce the PHP Namespace in core RFC for discussion.
> The RFC is authored by me together with George Peter Banyard and it's
> purpose
> is nothing more like to allow the use of PHP Namespace in the core.
>
> The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core


I think the php namespace for core is important to have, especially for
features that have more than a single, but multiple classes, grouping them
in a PHP internal namespace will be helpful to avoid weird prefixing.

With the Attributes RFC in mind, an earlier draft has used the namespace
PHP\Attributes that a few contributors rightly mentioned is a bad idea
without project wide standardization first.

For my taste, the RFC is great except the "A chance to clean up poor
design/naming decisions" section. It goes into politics and controversial
ideas that essentially are outside the scope of the RFC itself. So while
SPL and Reflection would benefit if we had the namespace before those APIs,
I am not sure they drive down the point of why we need this:

a.) Instead of changing SPL I believe most would pretty much agree that we
just need a complete replacement with a better API (pointing towards phpds
here might be a better example)
b.) Moving some new parts of Reflection into the namespace while keeping
others in the main namespace is extremely confusing, and we shouldn't
confuse users that way. Realistically this is an issue thats not going to
be changed.

I do like the Frame example, similar to token_get_all returning an array,
debug_backtrace could benefit from an object based representation. I would
reluctantly call it a "toy example", it is an actual example or not?

greetings
Benjamin

>
>
> Best Regards,
> Micha=C5=82 Brzuchalski
>

--00000000000051ffcc05a3b7bc3b--