Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109680
MIME-Version: 1.0
References: <CABdc3WoTeO4eTAoHCfqKyy8PWjrn97w9JXXhD88c3O9xPzp7QQ@mail.gmail.com>
 <CAOsHV+srDeL3FxcWkKZw3qZ8FaA3oBqOyPuot7fhjeyNZO46rw@mail.gmail.com>
 <CABdc3WrD_6czePZcvLQdmo_8bdK=4e7grrMEPAZP5s1fnAbDkw@mail.gmail.com>
 <5e974337.1c69fb81.62230.5d05SMTPIN_ADDED_MISSING@mx.google.com> <CAFPFaMK6441wugP+nwdXXZLLpRs3dMJb_kKNih1xBsDPs4Gt1g@mail.gmail.com>
In-Reply-To: <CAFPFaMK6441wugP+nwdXXZLLpRs3dMJb_kKNih1xBsDPs4Gt1g@mail.gmail.com>
Date: Thu, 16 Apr 2020 11:54:31 +0100
Message-ID: <CALKiJKoY=dg9JUMu=eb8Z8eSSsiHoT=nZ8ke-jWvbeRjMg7ZfQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b97bb605a366426a"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000b97bb605a366426a
Content-Type: text/plain; charset="UTF-8"

On Wed, 15 Apr 2020 at 20:54, G. P. B. <george.banyard@gmail.com> wrote:

> On Wed, 15 Apr 2020 at 19:24, Andrea Faulds <ajf@ajf.me> wrote:
> > We already have PHP language features relying on classes in the root
> > namespace (Closure, Throwable, ArrayAccess, etc) so the point Marcio
> > makes about inconsistency is nonetheless valid I think.
>
>
> The proposal is not to move everything into the PHP namespace.
> I would even argue that these interface make more sense in the global
> namespace as they are meant to be available to all users to implement
> and extend.
>
> [...]
>
> A more relevant example, in my eyes, is the current proposal of attributes.
> Engine attributes like JIT, NoJIT, and possibly in the future Deprecated
> and/or Final are features provided by the engine which should not have the
> possibility to be extended by end users, only consumed.
>


I don't really understand the distinction here. We currently have many
interfaces which exist to trigger "magic" in the Engine, some of which even
have special restrictions on how they can be used (e.g. you can't actually
implement Throwable or Traversable).

If we want to prevent users extending an attribute like JIT or NoJIT, we
can just mark the relevant class "final", and while extending ArrayAccess
or Countable is possible it isn't a particularly common use case, so that
doesn't seem like a meaningful difference.

If ArrayAccess didn't exist yet, and was proposed after this RFC was
accepted, my interpretation of the text would be that it must be placed in
the \PHP namespace, because it is "tightly coupled to the internals/engine
of the PHP interpreter".

Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000b97bb605a366426a--