Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109741
MIME-Version: 1.0
References: <CABdc3WoTeO4eTAoHCfqKyy8PWjrn97w9JXXhD88c3O9xPzp7QQ@mail.gmail.com>
 <CAEPJdukDAbNSjtS=VdjaMmUtA1fwN0eJ=EXKziTs3dgWUWZ4Rw@mail.gmail.com>
In-Reply-To: <CAEPJdukDAbNSjtS=VdjaMmUtA1fwN0eJ=EXKziTs3dgWUWZ4Rw@mail.gmail.com>
Date: Tue, 21 Apr 2020 09:31:06 +0200
Message-ID: <CABdc3WojJL=0qBB3_Beszaru8EX0JNQb-zBuMALy7+ai9i6viQ@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000058124e05a3c80048"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--00000000000058124e05a3c80048
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Benjamin,

pon., 20 kwi 2020 o 14:06 Benjamin Eberlei <kontakt@beberlei.de> napisa=C5=
=82(a):

> 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 the=
m
> 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 API=
s,
> 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 w=
e
> just need a complete replacement with a better API (pointing towards phpd=
s
> 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 woul=
d
> reluctantly call it a "toy example", it is an actual example or not?
>

The example with the Frame is something I'm thinking about to propose and
implement.

About the changing SPL. Bear in mind that the current proposal is only
about an agreement to allow the use of PHP namespace in the core.
@Benjamin: You suggest to skip the examples and arguments regarding poor
design/naming decisions with Reflection API ?

Those examples are put in the RFC to help understand the argumentation and
the result of this RFC should be the agreement that any future RFC
proposing an introduction of the tightly coupled with the PHP engine symbol
(and to mention the ones with PhpToken and PhpAttribute and family
could be perfect candidates) should not worry for the proposal to be
rejected because of the use of PHP namespace in core symbols.

BR,
Micha=C5=82 Brzuchalski

--00000000000058124e05a3c80048--