Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100685
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.52 as permitted sender)
To: Sara Golemon <pollita@php.net>, Zeev Suraski <zeev@zend.com>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <c7746903-2e3a-3e86-59c9-63483b244feb@gmx.de>
 <BY2PR02MB2986333DA75D8E49E444844AC6D0@BY2PR02MB298.namprd02.prod.outlook.com>
 <CAESVnVoJeRkvbXYoeqCj6D=SMo57-GDWxF4fWB7EAYhL1jy68w@mail.gmail.com>
Message-ID: <7f2d9e50-869d-4958-0ffe-249ff9cfd7f1@gmail.com>
Date: Sat, 16 Sep 2017 12:33:48 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CAESVnVoJeRkvbXYoeqCj6D=SMo57-GDWxF4fWB7EAYhL1jy68w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> If they were truly case-insensitive, I might agree.  However, as I've
> mentioned but will reiterate, they're not.  They're ASCII case
> insensitive, and that's a long cry from real case-insensitivity.  PHP
> 6 was planning to make case-insensitivity real but obviously that's
> dead and buried.

Should we really go there then? Full Unicode support for these things is
probably not going to happen, and I'd argue not many people actually
need it. Like it or not, it is not super-common to write PHP function
names or constant names in Russian, Farsi or hiragana. It demoes nice,
but I'm not sure that is a primary feature people would seek.

> This is ugly, but if I'm playing devil's advocate, it is consistent
> with the rest of the core runtime.

Frankly, I'd be fine with either - provided that we don't have more than
one kind (i.e. if we allow case-insensitive constants, no defining both
FOO and Foo).
But for cases-sensitivity I am worried about BC impact. We do have a
bunch of CI constants in extensions, including such widely used modules
as mcrypt. I'm not sure people use it in different cases, but hard to
really know... Maybe with suitable deprecation step it'd be OK, but not
sure how to make it work for CI constants.

-- 
Stas Malyshev
smalyshev@gmail.com