Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109857
MIME-Version: 1.0
References: <CANOvohpz5OzHZSxdABncBXRQfeF-XnKqpK8BBDQ8OeT+jBL96w@mail.gmail.com>
 <5ea5e72d.1c69fb81.ecd6b.8d05SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5ea5e72d.1c69fb81.ecd6b.8d05SMTPIN_ADDED_MISSING@mx.google.com>
Date: Mon, 27 Apr 2020 09:25:27 +0100
Message-ID: <CALKiJKpjwrdhnQT35myRRC-Sx-kFLzNQ6=a7J-_yEyzFm+2XVA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cbcee105a4417570"
Subject: Re: [PHP-DEV] Re: [RFC] PHP Namespace Policy
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000cbcee105a4417570
Content-Type: text/plain; charset="UTF-8"

On Sun, 26 Apr 2020 at 20:55, Mark Randall <marandall@php.net> wrote:

> I would be interested in hearing arguments why such a strategy adopted
> with great success by many of the most popular and well-developed
> languages, is inappropriate for PHP.
>


To me, the answer to that is quite simple: we have several hundred
functions, and several dozen classes and interfaces, which are not in such
a namespace; and we have millions of lines of code out in the world using
them. 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. It wouldn't make much sense, for instance, to have
PHP\str_contains but no plan to move str_replace.

The decisions you can make in version 8 of a language are inevitably
different from those you can make prior to version 1.

Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000cbcee105a4417570--