Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85969
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.177 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <A326B86EEE4C4E36B85455E01F355A22@gmail.com>
References: <EC598AEEF641411B949D685DF8262B4E@gmail.com>
	<CAFMT4Npcjz9kQjfSrKH3JwoyEUqCE6DzWnAaZ5c_idcuVAQ2fA@mail.gmail.com>
	<A326B86EEE4C4E36B85455E01F355A22@gmail.com>
Date: Mon, 27 Apr 2015 09:50:02 -0600
Message-ID: <CAFMT4NpQbhQDR0qbARK1ptGi1s+9eZanWCnTJgz666eBDTxk2Q@mail.gmail.com>
To: Nate Abele <nate.abele@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [RFC] Reserving More Types in PHP 7
From: levim@php.net (Levi Morrison)

On Sun, Apr 26, 2015 at 1:36 PM, Nate Abele <nate.abele@gmail.com> wrote:
> On Sunday, April 26, 2015, Levi Morrison <levim@php.net> wrote:
>
> On Sat, Apr 25, 2015 at 8:27 PM, Nate Abele <nate.abele@gmail.com> wrote:
>>> Dear Internals,
>>>
>>> I would like to discuss a small RFC for reserving more types in PHP 7:
>>> https://wiki.php.net/rfc/reserve_more_types_in_php_7
>>
>>
>> Welp, thanks for breaking my framework, everyone.
>>
>> It just *had* to be case-insensitive too, hm?
>
> I'm not sure what you want us to say.
>
>
> Well, it looks to me like all the discussion is around preventing class a=
nd
> namespace names like =E2=80=9Cstring=E2=80=9D, =E2=80=9Cfloat=E2=80=9D, e=
tc. Granted, PHP class names are
> case-insensitive, but how hard would it be to reserve these in a
> case-sensitive way?

Not necessarily hard, but it would create an inconsistency with other
types. PHP has plenty of consistency problems already; do you *really*
want to add a new one?

> Lithium, CakePHP, and Drupal all have String classes. These aren=E2=80=99=
t small
> projects. Not to mention the presumably untold numbers of developers who
> have hand-rolled =E2=80=98type=E2=80=99 classes into their projects while=
 waiting around for
> scalar type-hinting support to land. And everyone=E2=80=99s cool with bre=
aking all
> of these?

This was known at voting time, yes. Having an actual string type in
PHP was a separate RFC that was accepted -- realize that while my RFC
would have reserved it whether that other one passed or not the other
RFC *did* pass, so effectively the RFC you linked only reserved true,
false and null.

> I get that PHP 7 is the big opportunity to break backward compatibility, =
but
> yeesh, really? It=E2=80=99s like we=E2=80=99re not even trying anymore.

The number of code bases using a string class is quite small when you
compare it to the total number of PHP developers and code bases out
there.

I think you are blowing this out of proportion because you are
directly affected by it. I get it -- my website at work was really hit
hard in PHP 5, 5.3 and 5.4. We had some really crappy code that relied
on register globals, some deprecated session functions, magic quotes,
ext/mysql and other problems. After fixing each issue our codebase has
been better off.

If you can't afford to update an application then you need to
seriously think about that since that application apparently isn't
valuable enough for you to maintain it.