Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83643
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <54EC35ED.1080905@lsces.co.uk>
Date: Tue, 24 Feb 2015 08:27:25 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAEbg-4aR14ispgwzBmYxC1oFWPpKgdXTTmVcwJs_vRESKSw81A@mail.gmail.com> <CAB6YZuyheOLzsb3EOfWLip78hnWyoXXAuK6kF==uvDpNK_4row@mail.gmail.com>
In-Reply-To: <CAB6YZuyheOLzsb3EOfWLip78hnWyoXXAuK6kF==uvDpNK_4row@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine
From: lester@lsces.co.uk (Lester Caine)

On 24/02/15 08:02, Pavel Kouřil wrote:
>> 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?
> Hello,
> 
> I'd personally LOVE PHP being case-sensitive, but I think it's not possible.
> 
> Sure, frameworks and newer code will won't be broken, but what about
> the tons of "legacy" code? Personally, I saw too much code (and even
> examples in tutorials!) using stuff like MySQL_Query(). And case
> sensitivity would break this code without a doubt. (I know mysql ext
> is deprecated, but that's relevant right now, this is just one of many
> examples - the most common one I can think of, actually).
> 
> On the other hand, this could be fixed by running some migration
> scripts over code base, so maybe it's not THAT bad? Who knows.

It is fun that some areas are already case sensitive, such as the
returns from a database which under the SQL standard defaults to upper
case while the convention in code tends to be lower case. One has to
convert result arrays case often when trying to work cross platform.
However I think that the situation with regards Unicode seems to have
been lost in the current battlefield?

That a string value needs to be handled with mbstring is another little
problem which requires care when pushing strings around. Introducing
case-sensitive E_STRICT now would allow an eventual incorporation of
proper multilingual support later. Keeping some areas 'English only'
does not bother me, but the rest of the infrastructure has already moved
on so it is about time PHP joined modern practice?

One of the areas that many people may already have worked through is
moving from case-insensitive file names in Windows to case-sensitive
ones on other platforms which are now a lot more prevalent, so some of
the 'BC' problems are outside our control anyway.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk