Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109867
MIME-Version: 1.0
References: <CANOvohpz5OzHZSxdABncBXRQfeF-XnKqpK8BBDQ8OeT+jBL96w@mail.gmail.com>
 <5ea5e72d.1c69fb81.ecd6b.8d05SMTPIN_ADDED_MISSING@mx.google.com>
 <CALKiJKpjwrdhnQT35myRRC-Sx-kFLzNQ6=a7J-_yEyzFm+2XVA@mail.gmail.com>
 <F519C26E-E65E-46E5-9B70-74259310E774@newclarity.net> <29bd50e0-51d5-e8a1-10c4-bf89d42124c3@gmail.com>
 <AF105DAF-59A0-4DE7-B312-EB603A92B22E@newclarity.net>
In-Reply-To: <AF105DAF-59A0-4DE7-B312-EB603A92B22E@newclarity.net>
Date: Tue, 28 Apr 2020 09:45:17 +0100
Message-ID: <CALKiJKqnZ3vQ3QrLQH=YfZQsrKcfNHoH5ECb531PQvFauckxhw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000090fc3a05a455da53"
Subject: Re: [PHP-DEV] [RFC] PHP Namespace Policy
From: rowan.collins@gmail.com (Rowan Tommins)

--00000000000090fc3a05a455da53
Content-Type: text/plain; charset="UTF-8"

On Mon, 27 Apr 2020 at 23:22, Mike Schinkel <mike@newclarity.net> wrote:

> > On Apr 27, 2020, at 6:05 PM, Rowan Tommins <rowan.collins@gmail.com>
> wrote:
> >
> > So you'd be happy with PHP\str_contains and \str_replace next to each
> other indefinitely?
>
> Absolutely.   The benefits of having a PHP namespace would outweigh the
> lack of elegance above.
>


OK, on that part I simply disagree. One of the biggest complaints about
PHP's standard library is inconsistency; adding more to that by putting
what would feel like a random selection of functions (or classes) in a
namespace is a lot more than "lack of elegance". The benefits, on the other
hand, seem to be a theoretical saving of a one-off cost on the usually slim
chance that the name we choose conflicts with something in userland.



> OTOH I'm not sure why we could not have *both*  \str_replace and
> PHP\str_replace, with a plan to deprecate the former many versions from now.
>


Let me quote myself:

> So either we need a strong rationale and a concrete plan to move all of
those into the namespace, or we need a consistent policy on what goes in
and what stays out.


IMO neither a policy of "everything new goes in, but nothing moves" nor
"we'll remove the old names in 20 years time" is a workable plan; we need
something a lot more specific than that.




On Mon, 27 Apr 2020 at 23:19, Max Semenik <maxsem.wiki@gmail.com> wrote:

> All these prefixes, like PhpAttribute being discussed right now, only
decrease readability.

One prefix doesn't make a trend. "PhpToken" is a different case - it's a
token of PHP source code, so the prefix isn't anything to do with avoiding
name collisions, it's a natural clarification.

To be honest, I'd be perfectly happy with the attributes RFC using the
class name "Attribute", just as we use "Iterator", "Closure", "Exception",
etc, etc. At which point the whole thing's a non-issue.


On the other hand, I'd be fine with a new PHP\Attributes\* namespace being
used, but it would be good to have some guidelines on when namespaces are
and aren't going to be used, to avoid us having the debate every time.


Regards,
-- 
Rowan Tommins
[IMSoP]

--00000000000090fc3a05a455da53--