Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85960
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.170 as permitted sender)
Message-ID: <553DBEC4.7000609@gmail.com>
Date: Sun, 26 Apr 2015 21:44:52 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Nate Abele <nate.abele@gmail.com>
CC: internals <internals@lists.php.net>
References: <EC598AEEF641411B949D685DF8262B4E@gmail.com> <CAFMT4Npcjz9kQjfSrKH3JwoyEUqCE6DzWnAaZ5c_idcuVAQ2fA@mail.gmail.com> <A326B86EEE4C4E36B85455E01F355A22@gmail.com>
In-Reply-To: <A326B86EEE4C4E36B85455E01F355A22@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Well, it looks to me like all the discussion is around preventing
> class and namespace names like “string”, “float”, etc. Granted, PHP
> class names are case-insensitive, but how hard would it be to reserve
> these in a case-sensitive way?

With current engine - I'd say it is hard. We can't really say "class
names are case insentitive unless it's "string" or "float" or "boolean"
in which case they are case sensitive". Imagine how code implementing
such logic would look like, not to talk about the inconsistencies...

> Lithium, CakePHP, and Drupal all have String classes. These aren’t

Unfortunately, with scalar types we don't have much choice. I don't see
how scalar types and classes named "string" can coexist.

> I get that PHP 7 is the big opportunity to break backward
> compatibility, but yeesh, really? It’s like we’re not even trying
> anymore.

There was a lot of discussion about this topic. Right now, unless
there's a proposal to fix it that works, I don't see what can be done
about it.
-- 
Stas Malyshev
smalyshev@gmail.com