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: