Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83813
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@php.net>
To: "'Lester Caine'" <lester@lsces.co.uk>,
	<internals@lists.php.net>
References: <CAEbg-4aR14ispgwzBmYxC1oFWPpKgdXTTmVcwJs_vRESKSw81A@mail.gmail.com> <CAGa2bXa7z=8SSTW=EnsccrzgJhVB9Lvm-ayQLbUUu6MPUUZyYA@mail.gmail.com> <alpine.DEB.2.11.1502250936390.5941@whisky.home.derickrethans.nl> <54ED9E12.80808@lsces.co.uk>
In-Reply-To: <54ED9E12.80808@lsces.co.uk>
Date: Wed, 25 Feb 2015 19:33:41 +0100
Message-ID: <099301d05129$9461f0e0$bd25d2a0$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIPk8nXQdC7YxKTesF5vliHaD2pywJ92JufAaCEKEMBwclSk5xUKDgw
Content-Language: fr
Subject: RE: [PHP-DEV] [Discussion] Last chance for case-sensitive engine
From: francois@php.net (=?iso-8859-1?Q?Fran=E7ois_Laupretre?=)

Hi Lester,

I agree. The only way I imagine possible (maybe Derick can confirm),  is
adding an optional case-sensitive mode and, then, much later, make it =
the
default.

Unlike raising E_DEPRECATED on case-insensitive comparisons, this =
approach
is technically possible. The only probem I see is that people are =
shooting
down every new INI setting, whatever the need.

Regards

Fran=E7ois

> -----Message d'origine-----
> De=A0: Lester Caine [mailto:lester@lsces.co.uk]
> Envoy=E9=A0: mercredi 25 f=E9vrier 2015 11:04
> =C0=A0: internals@lists.php.net
> Objet=A0: Re: [PHP-DEV] [Discussion] Last chance for case-sensitive =
engine
>=20
> On 25/02/15 09:40, Derick Rethans wrote:
> > To be really honest, I don't think all of the pro's hold up. For a =
hash
> > check, there is no change really - the only change that is to remove =
the
> > zend_tolower. Previous discussions have IIRC shown that the =
performance
> > benefit is minimal. Compatibility with PSR's is also a moot point, =
as
> > there are just recommendations.
>=20
> There is still the matter of 'internationalization', which is
> technically a different RFC, but zend_tolower is only handling ASCII
> character set? So modifying that function where appropriate may be
> advantageous later.
>=20
> > However, there are a few extra cons: You are going to break
> > people's code on a large scale. I simply don't think it is worth it
> > (again, just like when this discussion popped up every year or so =
for
> > the last decade).
>=20
> Having been stung by the 'cons' already in reverse when moving =
perfectly
> stable code from windows to linux I'd actually say that it would have
> been a 'pro' if the mixed case stuff that previous programmers had =
used
> had been eliminated. I take a lot more care now ensuring that case IS
> consistent and if PHP nannied this in the same way it nannies some =
other
> style points, then I would put under the pro rather than con!
>=20
> Some of the BC areas being discussed do seem 'why put us through =
that',
> but unicode is still being pushed to the sidelines and this is one of
> those BC breaks which would help pave the way for a clean unicode core
> in the future.
>=20
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=3Dcontact
> 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
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php