RE: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols
| From: | François Laupretre | Date: | Sun, 25 Jan 2015 05:55:14 +0000 |
| Subject: | RE: [PHP-DEV] Proposal for PHP 7 : case-sensitive symbols | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-81108@lists.php.net to get a copy of this message | ||
Hi,
> De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo Ohgaki
>
> > I would like to propose that namespaces, functions, and classes become
> > case-sensitive (constants are already case-sensitive). Actually, I never
> > understood why they are case-insensitive. Even if the performance gain is
> > negligible, I think it could be the right time to question this.
> >
>
> I'm writing this mail without reading current zend code.
>
> Anyway, is it feasible to raise E_DEPRECATE without much performance
> penalty?
> For example,
>
> if (!strcmp(name, name_to_be_searched)) {
> do_something;
> } else if (!strcasecmp(name, name_to_be_searched) {
> rase_error;
> do_something;
> }
>
> Duplicated codes may be removed by macro. strcasecmp() checks may be
> removed
> 10 years later or more.
Unfortunately, raising an E_DEPRECATED on case-sensitive mismatch is a huge work, as
case-insensitivity appears in a lot of locations throughout the core. And the macro approach is not
possible.
Actually, case insensitivity goes well beyond class and function names: it also includes namespaces,
scope resolution operators (self, parent, static), class magic methods, method names (properties
are already case-sensitive), language keywords, and some stream wrapper protocols (like file and
zlib). All these case insensitive comparisons are done in a variety of ways, at various locations in
the code. Most store and compare names converted to lowercase (which implies a problem with Unicode
as correct conversion with an unknown character set is impossible), some use strncasecmp...
So, making the code case-sensitive would be a important work, but raising an E_DEPRECATED message
would require much more work. Unfortunately, you can forget the idea of a macro that can be removed
anytime in the future :)
Cheers
François