Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71693
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain oracle.com designates 141.146.126.69 as permitted sender)
Message-ID: <52E7FCA2.70009@oracle.com>
Date: Tue, 28 Jan 2014 10:53:22 -0800
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAEZPtU6749gD2a9BDzdTQoBPUsPDSspjukZvFw9qwt=Le5Q1zQ@mail.gmail.com>	<52E7D67D.1030308@ajf.me> <CAEZPtU6M3_x7Kv1U8gOAx3L3ZDZxt6UiV8RLxaY3voYUvnoqFw@mail.gmail.com> <52E7F55F.7090801@ajf.me>
In-Reply-To: <52E7F55F.7090801@ajf.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] some thoughts about php 6
From: christopher.jones@oracle.com (Christopher Jones)



On 01/28/2014 10:22 AM, Andrea Faulds wrote:
>
>
> On 28/01/14 16:13, Pierre Joye wrote:
>> 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
>> :)
>
> I don't care about coding style. I care about sanity here, and I think case-insensitivity leads to more problems than it solves, especially, as others have pointed out, when autoloading comes into play.
>
> A case-fixing tool could be run once on existing codebases, break no backwards compatibility, and make those codebases work on PHP 6.
>

Regardless of how we might wish the language had originally been
created, keeping compatibility is a very, very strong argument against
some of the recent compatibility-breaking RFCs and internals
discussions. Whether the pros outweigh the cons on a particular RFC is
a case-by-case question.

I agree with Pierre: make a strong RFC (and patch etc) and it can be
voted on.

The Python community has similar "discussions", e.g. see the link in:
https://twitter.com/ghrd/status/427879604070526976

Chris

-- 
christopher.jones@oracle.com  http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html