Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60241
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL+t6cGksdaPJUanXxRcV25dNz2bPXd72SZJ-Yjs0M9ni28Nyw@mail.gmail.com>
References: <jmrdbg$bh4$1@dough.gmane.org>
	<CAF+90c8NxUvXOEbFbN=U6QBNqvHLsa9Jfgx_1fpWss5ASCX11Q@mail.gmail.com>
	<CAL0xaBGfw35FPFTs=CZwc4OLDzB9N6N2uHdQsi8vmagmB-qVXA@mail.gmail.com>
	<CAL+t6cGM7gBWsiPYn8EbTEZm=OBb1=vrWzbyURRTgCvvKOUwLg@mail.gmail.com>
	<CAL+t6cECGQHJyxKew=U5t_wJV=8fKf6X-UaiwiEChy2=UE0=uw@mail.gmail.com>
	<CAGsnKxanO0oraHHB=+v61=-y7WtQR5vbN1fxHHzcagjFncmveg@mail.gmail.com>
	<CAL+t6cGksdaPJUanXxRcV25dNz2bPXd72SZJ-Yjs0M9ni28Nyw@mail.gmail.com>
Date: Fri, 20 Apr 2012 10:57:18 -0700
Message-ID: <CAKOpQSxbmcn2wxLuUMOpLd0NbNL==dV3cm4rhWmW_rNsjukNFw@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: John LeSueur <john.lesueur@gmail.com>, Arvids Godjuks <arvids.godjuks@gmail.com>, 
	internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016e6dee821fa5c8a04be200473
Subject: Re: [PHP-DEV] Complete case-sensitivity in PHP
From: kris.craig@gmail.com (Kris Craig)

--0016e6dee821fa5c8a04be200473
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 20, 2012 at 8:44 AM, Sherif Ramadan <theanomaly.is@gmail.com>wrote:

> > But in order to be case insensitive, PHP needs to know that
> strtolower("A")
> > == 'a'. So if you use Cyrilic for userland functions/classes, php needs a
> > cyrillic aware strtolower function. Then the problem is that core
> > classes/functions need to use a plain ASCII strtolower for case
> > insensitivity. So you cannot both write code in cyrillic and interface
> with
> > plain ASCII internals. One possible, but less than optimal solution is to
> > first try a locale aware strtolower, then try a plain ascii strtolower
> when
> > looking up symbols.
> >
> > John
>
> I can see the confusion about PHP's case-sensitivity and how it mixes
> and matches between case-insensitive functions/classes/(arguably even
> constants), and case-sensitive variable names, for example.
>
> Its naming rules are a little bit inconsistent in that regard. I just
> don't see a point in making it completely locale aware. The fact that
> you can do soefunc() and SOMEFUNC() and still invoke the same function
> is a benefit.


Could you elaborate?  Aside from making PHP forgiving of typos and overall
laziness on the part of the coder, and of course BC notwithstanding, I'm
not sure I understand what benefit there is to preserving this inconsistent
behavior.


> And I suppose for those using UTF-8 encoded function
> names it might be convenient to make them case-sensitive as well. I'm
> not going to argue that it's not. I'm just going to say that it
> doesn't seem to be a significant problem.
>

When I was at Microsoft, I got into a little argument with some folks from
the Windows division about this very issue-- except, in this case, it was
about case-sensitivity in the filesystem.  They essentially made the same
argument; i.e. "Why would you want 'Find.exe' and 'find.exe' to be two
separate things?!"  I countered that I may want to add a library to the
PATH that contains a file with the same name, such as UnxUtils.  "Why would
you want to do that?!  Windows' find.exe is way better than the Unix one,
anyway!"....  And then my brain exploded.

Turkish localization notwithstanding (I confess that I know absolutely *
nothing* about that lol), one possible use-case could be if you're
including an external library/framework that contains a function with the
same name but different case.  I'm not sure how likely that is, mind you,
but I can see that as one potential benefit.  Either way, I guess my point
is that the arguments for/against this seem to parallel the arguments for
Windows-style fso case-insensitivity vs. Unix-style fso case-sensitivity.

--Kris


> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0016e6dee821fa5c8a04be200473--