RE: [PHP-DEV] [Discussion] Last chance for case-sensitive engine
| From: | François Laupretre | Date: | Thu, 26 Feb 2015 00:36:49 +0000 |
| Subject: | RE: [PHP-DEV] [Discussion] Last chance for case-sensitive engine | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-83857@lists.php.net to get a copy of this message | ||
Pierre,
> De : Pierre Joye [mailto:pierre.php@gmail.com]
>
> > I case we would designed a new language I would rise two hands.
> > Changing, syntax in an existent widely used language is an additional pain
> > for users.
> > Technically it shouldn't be very difficult to remove support for
> > case-insensitivity, and it'll even improve speed and memory consumption,
> > but I don't think it costs the compatibility break.
>
> I fully agree and why I will vote no on that. Even if I know many
> projects that won't even notice such changes. But I also have no idea
> how many 1000s projects out there won't be as happy.
Don't worry, I won't bother anyone with a vote at this stage. I have started an RFC to
keep a track and explore the topic but it is a complex subject. It is even *many* more or less
independent complex subjects.
Anyway, some may be easier than others, for different reasons (just personal opinions, to be
confirmed in each case) :
- Namespaces are relatively new. We might expect code using them to be 'cleaner',
- We can probably quite easily deprecate support (internal and userland) for case-insensitive
functions by just making null, false, and true case-sensitive and adding new NULL, FALSE, TRUE,
Null, False, and True. Probably no need for fAlSe or tRUE :)
- __halt_compiler() does not represent much but has the benefit of being an easy case :)
- magic methods are already more risky but may be imagined with some case-sensitive aliases added.
The rest is more complex, and would necessitate extensive impact studies.
Regards
François