Re: [Discussion] Last chance for case-sensitive engine
| From: | Pierre Joye | Date: | Wed, 25 Feb 2015 19:16:20 +0000 |
| Subject: | Re: [Discussion] Last chance for case-sensitive engine | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-83816@lists.php.net to get a copy of this message | ||
On Wed, Feb 25, 2015 at 10:52 AM, Dmitry Stogov <dmitry@zend.com> wrote:
> Hi Alexander,
>
> On Tue, Feb 24, 2015 at 10:48 AM, Alexander Lisachenko <
> lisachenko.it@gmail.com> wrote:
>
>> Morning!
>>
>> I want to ask this question one more time before PHP7 feature freeze: can
>> we the engine case sensitive from PHP>=7.0?
>>
>> There is a draft for that:
>> https://wiki.php.net/rfc/case-sensitivity
>> (mostly empty), so I decided to ask this question in the internals mail
>> list.
>>
>> Pros: more simple O(1) hash table checks for properties, functions,
>> methods, classes without strtolower normalization on the engine/parser
>> level. Consistency with unicode class names (yes, they are case sensitive,
>> check http://3v4l.org/ia0pc), consistency with exisiting
>> PSR0,4 standards
>> (case sensitive mapping of class names to the file names)
>>
>> From my experience, all modern PHP framework don't use case-insensitive
>> code, so chance to break anything for them is really low.
>>
>> Cons: on the extension level things aren't so good and can be some BC
>> breaks (like with phpng)
>>
>> Possible ways:
>>
>> 1) Keep PHP engine case-insensitive for PHP7
>> 2) Make PHP engine case-sensitive since PHP7 with possible minor BC breaks
>> in the extensions (this breaks can be easily fixed)
>> 3) Add a compile-time switch, eg. --with-case-sensitivity to the
>> configuration to have an ability to build PHP with sensitivity and make
>> this option enabled by default since next major version (PHP>=8.0). Add
>> deprecation notices in 7.x
>>
>> Thoughts?
>>
>
> I case we would designed a new language I would rise two hands.
> Changing, syntax in an existent widely used language is an additional pain
> for users.
> Technically it shouldn't be very difficult to remove support for
> case-insensitivity, and it'll even improve speed and memory consumption,
> but I don't think it costs the compatibility break.
I fully agree and why I will vote no on that. Even if I know many
projects that won't even notice such changes. But I also have no idea
how many 1000s projects out there won't be as happy.
--
Pierre
@pierrejoye | http://www.libgd.org