Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60233
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <jmrdbg$bh4$1@dough.gmane.org>
References: <jmrdbg$bh4$1@dough.gmane.org>
Date: Fri, 20 Apr 2012 16:25:29 +0300
Message-ID: <CAL0xaBFy-MjgMRLf9gZsRgGgOoM8n2=5PNAGmZNiV3rJEQrjXQ@mail.gmail.com>
To: "C.Koy" <can5koy@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=14dae93408591b283404be1c3a2b
Subject: Re: [PHP-DEV] Complete case-sensitivity in PHP
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--14dae93408591b283404be1c3a2b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In past years such switches where deprecated and removed (in 5.3 most of
them, in 5.4 finally all that stuff is gone for good). So any solution,
involving a switch that modifies how code is executed will hit a wall of
resistance. It's the lesson that was learned the hard way.

So it may be the case to make PHP case-sensetive. There will be code
broken, probably a lot. But that can be fixed, and I personally always
write with respect to char case, so that will be no problem for me.

20 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2012 =D0=B3. 13:20 =D0=BF=D0=BE=D0=
=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C C.Koy <can5koy@gm=
ail.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

> Hi,
>
> This post is about bug #18556 (https://bugs.php.net/bug.php?**id=3D18556<=
https://bugs.php.net/bug.php?id=3D18556>)
> which is a decade old.
>
> As the recent comments on that page indicate, there's not a deterministic
> way to resolve this issue, apart from eliminating tolower() calls for
> function/class names during lookup. Hence totally case-sensitive PHP.
>
> Before opposing with "No, this will break a lot of existing code!", note
> that I'm not suggesting a static permanent change in the engine; rather a
> runtime option that will need to be enabled (cli option, INI setting),
> without which PHP will work as before.
>
> Since I'm not well versed in the workings of Zend engine, I solicit the
> wisdom/experience of people in this list: Is this doable in a practical
> way, without making grand changes in Zend?
>
> best regards,
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--14dae93408591b283404be1c3a2b--