Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110253
MIME-Version: 1.0
References: <CAEPJdum6xCwABjpor1YYvuosSB1dEb4xnCZEMABKsEEvNXvcQQ@mail.gmail.com>
 <CAF+90c_QNBU-cc_3g7wrCFb8b_FbGR-hOFs2XOk1aJdTsXh=Ag@mail.gmail.com> <CAEPJdum2MdqARRZU8YhrxEtsPckAOzS_SXHZnD-=GdZHt1+Q-Q@mail.gmail.com>
In-Reply-To: <CAEPJdum2MdqARRZU8YhrxEtsPckAOzS_SXHZnD-=GdZHt1+Q-Q@mail.gmail.com>
Date: Fri, 22 May 2020 17:49:10 +0200
Message-ID: <CAF+90c-VOB_yDRaFatFuYa8W6ShZZ-PS-Pm7f7xUsOTnyV-hxQ@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ee676005a63e9278"
Subject: Re: [PHP-DEV] [RFC] Amendments to Attributes
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000ee676005a63e9278
Content-Type: text/plain; charset="UTF-8"

On Fri, May 22, 2020 at 5:29 PM Benjamin Eberlei <kontakt@beberlei.de>
wrote:

>
>
> On Fri, May 22, 2020 at 1:08 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei <kontakt@beberlei.de>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> the Attributes RFC was rather large already, so a few things were left
>>> open
>>> or discussions during the vote have made us rethink a things.
>>>
>>> https://wiki.php.net/rfc/attribute_amendments
>>>
>>> These points are handled by the Amendments RFC to Attributes:
>>>
>>> 1. Proposing to add a grouped syntax <<Attr1, Attr2>
>>
>> 2. Rename PhpAttribute to Attribute in global namespace (independent of
>>> the
>>> namespace RFC)
>>>
>>
>> As was mentioned in one of the previous discussions, we expect that PHP
>> is going to ship more language-provided attributes in the future. With this
>> proposal we have the "Attribute" attribute, but I expect we'll at least
>> have "Deprecated" as well, and probably also something along the lines of
>> "Jit" or "NoJit". While I'm happy with "Attribute" living in the global
>> namespace, I don't really think we'd want to introduce "Jit" as a class in
>> the global namespace. The name is simply to generic and does not indicate
>> that this is part of the attribute system. We'd be forced to go with things
>> like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to
>> me, as we're just reinventing namespaces to avoid using them...
>>
>> As such, I would suggest to introduce a common namespace for all
>> attributes provided by PHP. This means we'd have Attributes\Attribute,
>> Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay
>> with the PHP\Attributes\Deprecated variant, but that's a separate question).
>>
>
> Deprecated would be an "engine level" feature, but Opcache is an
> extension, so it can have its own namespace "Opcache\Jit". The namespace
> RFC goes that far mentioning only " core symbols which cannot be unbundled"
> should go into a PHP namespace, which would exclude Opcache (and its
> "sub-extension" JIT). https://wiki.php.net/rfc/php-namespace-in-core
>
> So for me that is not necessarily an argument against Attribute in global
> NS, because Jit would live in Opcache\.
>

Interesting point. I think this is more an argument against using a "PHP"
vendor namespace, than against using an "Attributes" namespace. JIT is not
"really" an opcache feature, it just lives in opcache right now because it
happens to be convenient. There are long term plans to move the
optimization-related functionality from opcode into core, and JIT should
also live in core (and I think there are plenty of workloads that are
interested in JIT without the SHM caching). Given that context, calling the
attribute Opcache\Jit seems somewhat ill-advised. I also think we'd want to
provide this attribute independently of whether opcache is actually loaded,
because annotating functions with it would be rather problematic if it's
not always available...

Ultimately I'm okay with going with just "Attribute" here, but we need to
acknowledge that this comes with future obligations. In particular,
introducing a "Deprecated" class is a "no" from me, because the name is too
generic and does not indicate that this is part of the attribute system. It
will need to be "DeprecatedAttribute" (or "Attribute_Deprecated", ugh).
Which also means that you need to "use DeprecatedAttribute as Deprecated"
to use it. This isn't terrible, but I also don't think it's ideal.

Regards,
Nikita

--000000000000ee676005a63e9278--