Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71682
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.204 cause and error)
Message-ID: <52E7E0BA.3070509@lsces.co.uk>
Date: Tue, 28 Jan 2014 16:54:18 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAEZPtU6749gD2a9BDzdTQoBPUsPDSspjukZvFw9qwt=Le5Q1zQ@mail.gmail.com>	<52E7D67D.1030308@ajf.me> <CAEZPtU6M3_x7Kv1U8gOAx3L3ZDZxt6UiV8RLxaY3voYUvnoqFw@mail.gmail.com>
In-Reply-To: <CAEZPtU6M3_x7Kv1U8gOAx3L3ZDZxt6UiV8RLxaY3voYUvnoqFw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] some thoughts about php 6
From: lester@lsces.co.uk (Lester Caine)

Pierre Joye wrote:
>>> >>- Case sensitivity
>>> >>    . Even with ini setting, which will be most likely system wild, will
>>> >>bring a major breakage for almost every single app out there. I do not
>>> >>see any gain to do it.
>> >
>> >
>> >On the contrary, I'd argue a lot of applications use lowercase names anyhow.
>> >And as I've mentioned before, it'd be trivial to write a tool to
>> >automatically correct existing source.

> Anyone not being a developer will never use it. Let alone conservative
> projects, or already released applications. There is no gain. However
> there are tools already to apply whatever CS one wishes to existing
> source code, or to check CS on commit. That's what one can uses case
> sensitive naming without us having to break everything out there. I
> think we can disagree on that and do not discuss that forever, if
> there is a RFC about it, we will vote on it and that's it:)  My
> mistake was to send this mail too early, more important points coming
> :)

For people who only work on Windows systems then the problem does not exist as 
such, but continually fighting legacy projects that originated in that 
environment, trying to clear up lax case usage, pinning this down makes sense to 
me. Add to this the problem that allowing proper Unicode support across the 
board, then simply allowing limited case 'insensitivity' going forward does not 
make sense either. Comments have been made about not allowing foo/Foo at the 
same time, and yes this can be a problem when involving Windows file names but I 
think that is a different problem anyway. I am open to some mechanism to help 
flag that problem, but I don't see the general simplification would cause any 
problem if a project has used the same case everywhere.

I've just been reworking a project that works fine on windows, but fell flat on 
Linux because a number of directory names used were different cases to the 
classes in them ...

-- 
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