Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109865
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <29bd50e0-51d5-e8a1-10c4-bf89d42124c3@gmail.com>
Date: Mon, 27 Apr 2020 18:22:49 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <AF105DAF-59A0-4DE7-B312-EB603A92B22E@newclarity.net>
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>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC] PHP Namespace Policy
From: mike@newclarity.net (Mike Schinkel)

> On Apr 27, 2020, at 6:05 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> 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.

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.


> Or, more in line with your proposal, a hypothetical =
PHP\Iterators\FractallyAwesomeIterator next to \InifiniteIterator, =
\LimitIterator, etc? Or did you have some stronger definition of "newer =
things" in mind?

Newer things =3D=3D=3D things that come chronologically after an RFC is =
approved.

If we have to ensure elegance across the entire language it becomes very =
hard to ever improve it as new things are usually inconsistent with =
less-elegant prior approaches.


> I don't really see what such an arbitrary split would gain us, other =
than a lot of confusion.

The "arbitrary split" is not what where we would see the gain, that is =
just an unfortunately inconvenience.

The gain would come from having a PHP namespace where we don't have to =
worry about naming conflicts in user-land moving forward.

The former is an acceptable tradeoff to gain the latter.  IMO anyway.  =
But YMMV.


> Importantly, it wouldn't be following the lead of the other languages =
and frameworks you mentioned, which was the specific point I was =
responding to.

Did I mention other languages and frameworks?  I just wrote the simple =
reply above saying "newer things go in, older ones stay out."


-Mike