[Discussion] Last chance for case-sensitive engine

9 years ago by pajousek@gmail.com — view source

unread

On Tue, Feb 24, 2015 at 8:48 AM, Alexander Lisachenko
lisachenko.it@gmail.com wrote:

Morning!

I want to ask this question one more time before PHP7 feature freeze: can
we the engine case sensitive from PHP>=7.0?

There is a draft for that: https://wiki.php.net/rfc/case-sensitivity
(mostly empty), so I decided to ask this question in the internals mail
list.

Pros: more simple O(1) hash table checks for properties, functions,
methods, classes without strtolower normalization on the engine/parser
level. Consistency with unicode class names (yes, they are case sensitive,
check http://3v4l.org/ia0pc), consistency with exisiting PSR0,4 standards
(case sensitive mapping of class names to the file names)

From my experience, all modern PHP framework don't use case-insensitive
code, so chance to break anything for them is really low.

Cons: on the extension level things aren't so good and can be some BC
breaks (like with phpng)

Possible ways:

Keep PHP engine case-insensitive for PHP7

Make PHP engine case-sensitive since PHP7 with possible minor BC breaks
in the extensions (this breaks can be easily fixed)

Add a compile-time switch, eg. --with-case-sensitivity to the
configuration to have an ability to build PHP with sensitivity and make
this option enabled by default since next major version (PHP>=8.0). Add
deprecation notices in 7.x

Thoughts?

Hello,

I'd personally LOVE PHP being case-sensitive, but I think it's not possible.

Sure, frameworks and newer code will won't be broken, but what about
the tons of "legacy" code? Personally, I saw too much code (and even
examples in tutorials!) using stuff like MySQL_Query(). And case
sensitivity would break this code without a doubt. (I know mysql ext
is deprecated, but that's relevant right now, this is just one of many
examples - the most common one I can think of, actually).

On the other hand, this could be fixed by running some migration
scripts over code base, so maybe it's not THAT bad? Who knows.

Regards
Pavel Kouril

9 years ago by Lester Caine — view source

unread

I want to ask this question one more time before PHP7 feature freeze: can

we the engine case sensitive from PHP>=7.0?

There is a draft for that: https://wiki.php.net/rfc/case-sensitivity
(mostly empty), so I decided to ask this question in the internals mail
list.

Pros: more simple O(1) hash table checks for properties, functions,
methods, classes without strtolower normalization on the engine/parser
level. Consistency with unicode class names (yes, they are case sensitive,
check http://3v4l.org/ia0pc), consistency with exisiting PSR0,4 standards
(case sensitive mapping of class names to the file names)

From my experience, all modern PHP framework don't use case-insensitive
code, so chance to break anything for them is really low.

Cons: on the extension level things aren't so good and can be some BC
breaks (like with phpng)

Possible ways:

Keep PHP engine case-insensitive for PHP7

Make PHP engine case-sensitive since PHP7 with possible minor BC breaks
in the extensions (this breaks can be easily fixed)

Add a compile-time switch, eg. --with-case-sensitivity to the
configuration to have an ability to build PHP with sensitivity and make
this option enabled by default since next major version (PHP>=8.0). Add
deprecation notices in 7.x

Thoughts?
Hello,

I'd personally LOVE PHP being case-sensitive, but I think it's not possible.

Sure, frameworks and newer code will won't be broken, but what about
the tons of "legacy" code? Personally, I saw too much code (and even
examples in tutorials!) using stuff like MySQL_Query(). And case
sensitivity would break this code without a doubt. (I know mysql ext
is deprecated, but that's relevant right now, this is just one of many
examples - the most common one I can think of, actually).

On the other hand, this could be fixed by running some migration
scripts over code base, so maybe it's not THAT bad? Who knows.

It is fun that some areas are already case sensitive, such as the
returns from a database which under the SQL standard defaults to upper
case while the convention in code tends to be lower case. One has to
convert result arrays case often when trying to work cross platform.
However I think that the situation with regards Unicode seems to have
been lost in the current battlefield?

That a string value needs to be handled with mbstring is another little
problem which requires care when pushing strings around. Introducing
case-sensitive E_STRICT now would allow an eventual incorporation of
proper multilingual support later. Keeping some areas 'English only'
does not bother me, but the rest of the infrastructure has already moved
on so it is about time PHP joined modern practice?

One of the areas that many people may already have worked through is
moving from case-insensitive file names in Windows to case-sensitive
ones on other platforms which are now a lot more prevalent, so some of
the 'BC' problems are outside our control anyway.

--
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

9 years ago by Yasuo Ohgaki — view source

unread

Hi Alexander,

On Tue, Feb 24, 2015 at 4:48 PM, Alexander Lisachenko <
lisachenko.it@gmail.com> wrote:

There is a draft for that: https://wiki.php.net/rfc/case-sensitivity
(mostly empty), so I decided to ask this question in the internals mail
list.

Pros: more simple O(1) hash table checks for properties, functions,
methods, classes without strtolower normalization on the engine/parser
level. Consistency with unicode class names (yes, they are case sensitive,
check http://3v4l.org/ia0pc), consistency with exisiting PSR0,4 standards
(case sensitive mapping of class names to the file names)

From my experience, all modern PHP framework don't use case-insensitive
code, so chance to break anything for them is really low.

Cons: on the extension level things aren't so good and can be some BC
breaks (like with phpng)

Possible ways:

Keep PHP engine case-insensitive for PHP7

Make PHP engine case-sensitive since PHP7 with possible minor BC breaks
in the extensions (this breaks can be easily fixed)

Add a compile-time switch, eg. --with-case-sensitivity to the
configuration to have an ability to build PHP with sensitivity and make
this option enabled by default since next major version (PHP>=8.0). Add
deprecation notices in 7.x

INI switch is better. Compiler switch would not work well, since user cannot
check their code easily.

PHP7 - introduce case sensitivity switch off by default
PHP8 - make case sensitivity switch on by default
PHP9 - remove case sensitivity switch

Case sensitivity is not mandatory. It would be better to choose long term
approach.
There will be enough time for users to adopt case sensitive names. In mean
time,
we have no BC in PHP7. It's good for PHP7. IMHO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Alain Williams — view source

unread

INI switch is better. Compiler switch would not work well, since user cannot
check their code easily.

PHP7 - introduce case sensitivity switch off by default
PHP8 - make case sensitivity switch on by default
PHP9 - remove case sensitivity switch

+1

There will be those who just won't make changes and for who PHP9 will be a
''surprise'' - but similar happened with the removal of register globals.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h

9 years ago by francois@php.net — view source

unread

Hi,

I started the RFC because I first wanted to test the idea on the list and
have a place to store every case-insensitive I could find in PHP.

I stopped for several reasons :

The reactions were mostly negative, with a majority of 'breaks much,
brings nothing' opinions,
Crawling through the code, I discovered that code to handle case
insensitivity was spread all around PHP. Example: I thought that function
and method names could be made case-sensitive by modifying a limited number
of lines of code. Actually, it seems it is handled in a more or less
redundant way in a lot of locations. So, I quickly realized that
implementation would be extremely complex.
A lot of PHP code is, knowingly or not, using PHP case insensitivity.
A patch to make PHP case sensitive would be very complex, and providing a
two-mode mechanism still much more. It would require in many cases to
provide another case-sensitive test after each case-insensitive one and
raise an error if both don't match. We must do that because case-insensitive
comparisons are done using a case-sensitive comparison of two strings
previously converted to lowercase. It would also require to store every
class/function/method names twice, as they are currently stored in lowercase
form. As lowercase names are transmitted as strings around the code, it is
very complex to keep the link with the original value. So, to summarize, I
now consider that providing a compatibility 'notice-only' mode is
practically impossible.

So, while it seemed attractive at first, I stopped working on it.

I'll maybe revive it one day or another but, at the moment, it is not worth
the pain working on a very complex change that would have almost no chance
to pass.

Regards

François

-----Message d'origine-----
De : Alain Williams [mailto:addw@phcomp.co.uk]
Envoyé : mardi 24 février 2015 10:32
À : internals@lists.php.net
Objet : Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

INI switch is better. Compiler switch would not work well, since user
cannot
check their code easily.

PHP7 - introduce case sensitivity switch off by default
PHP8 - make case sensitivity switch on by default
PHP9 - remove case sensitivity switch

+1

There will be those who just won't make changes and for who PHP9 will be a
''surprise'' - but similar happened with the removal of register globals.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer,
IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h

9 years ago by Yasuo Ohgaki — view source

unread

Hi Francois,

On Wed, Feb 25, 2015 at 8:45 AM, François Laupretre francois@php.net
wrote:

I stopped for several reasons :

The reactions were mostly negative, with a majority of 'breaks much,
brings nothing' opinions,

Crawling through the code, I discovered that code to handle case
insensitivity was spread all around PHP. Example: I thought that function
and method names could be made case-sensitive by modifying a limited
number
of lines of code. Actually, it seems it is handled in a more or less
redundant way in a lot of locations. So, I quickly realized that
implementation would be extremely complex.

A lot of PHP code is, knowingly or not, using PHP case insensitivity.

A patch to make PHP case sensitive would be very complex, and
providing a
two-mode mechanism still much more. It would require in many cases to
provide another case-sensitive test after each case-insensitive one and
raise an error if both don't match. We must do that because
case-insensitive
comparisons are done using a case-sensitive comparison of two strings
previously converted to lowercase. It would also require to store every
class/function/method names twice, as they are currently stored in
lowercase
form. As lowercase names are transmitted as strings around the code, it is
very complex to keep the link with the original value. So, to summarize, I
now consider that providing a compatibility 'notice-only' mode is
practically impossible.

So, while it seemed attractive at first, I stopped working on it.

Sounds reasonable.
Zend does comparison/conversion various places indeed. "Propose
& announce it now, then implement it PHP8" may work. We may get a
little simpler Engine for PHP8.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by francois@php.net — view source

unread

Hi,

The most important point, IMO, is that it will be extremely complex to provide a ‘deprecated’ transition step.

I won’t have time to work on it during the next month (will be in Africa starting next Saturday). So feel free to take over the RFC and propose something for the future.

Regards

François

De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo Ohgaki
Envoyé : mercredi 25 février 2015 03:07
À : francois
Cc : Alain Williams; internals@lists.php.net
Objet : Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

Hi Francois,

I stopped for several reasons :

The reactions were mostly negative, with a majority of 'breaks much,
brings nothing' opinions,

Crawling through the code, I discovered that code to handle case
insensitivity was spread all around PHP. Example: I thought that function
and method names could be made case-sensitive by modifying a limited number
of lines of code. Actually, it seems it is handled in a more or less
redundant way in a lot of locations. So, I quickly realized that
implementation would be extremely complex.

A lot of PHP code is, knowingly or not, using PHP case insensitivity.

A patch to make PHP case sensitive would be very complex, and providing a
two-mode mechanism still much more. It would require in many cases to
provide another case-sensitive test after each case-insensitive one and
raise an error if both don't match. We must do that because case-insensitive
comparisons are done using a case-sensitive comparison of two strings
previously converted to lowercase. It would also require to store every
class/function/method names twice, as they are currently stored in lowercase
form. As lowercase names are transmitted as strings around the code, it is
very complex to keep the link with the original value. So, to summarize, I
now consider that providing a compatibility 'notice-only' mode is
practically impossible.

So, while it seemed attractive at first, I stopped working on it.

Sounds reasonable.
Zend does comparison/conversion various places indeed. "Propose
& announce it now, then implement it PHP8" may work. We may get a
little simpler Engine for PHP8.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Yasuo Ohgaki — view source

unread

Hi Francois,

On Wed, Feb 25, 2015 at 2:37 PM, François Laupretre francois@php.net
wrote:

I won’t have time to work on it during the next month (will be in Africa
starting next Saturday). So feel free to take over the RFC and propose
something for the future.

It's off topic for this thread, but are you finished DbC by annotation RFC?
Can I start voting with current state? Or do you still have time for the
RFC?
(I'll start [RFC][DISCUSSION] first, of course)

Regards,

P.S. I don't have time for this RFC neither.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by francois@php.net — view source

unread

Hi Yasuo,

I won’t have time to work more on DbC before one month. As I said, I am leaving Saturday moring for 3 weeks, and use the 2 days left to rewrite the coercive STH RFC with Zeev, and work on the corresponding patch with Dmitry.

So, feel free to put it to vote. Just reference my one as ‘alternate work that is not ready for 7.0 and is suspended until we have approval on scalar type hints mechanism’. Because, except for the fact they convert input, type hints are essentially contracts.

Regards

François

De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo Ohgaki
Envoyé : mercredi 25 février 2015 08:20
À : francois
Cc : Alain Williams; internals@lists.php.net
Objet : Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

Hi Francois,

I won’t have time to work on it during the next month (will be in Africa starting next Saturday). So feel free to take over the RFC and propose something for the future.

It's off topic for this thread, but are you finished DbC by annotation RFC?

Can I start voting with current state? Or do you still have time for the RFC?

(I'll start [RFC][DISCUSSION] first, of course)

Regards,

P.S. I don't have time for this RFC neither.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Derick Rethans — view source

unread

On Tue, Feb 24, 2015 at 4:48 PM, Alexander Lisachenko <
lisachenko.it@gmail.com> wrote:

There is a draft for that: https://wiki.php.net/rfc/case-sensitivity
(mostly empty), so I decided to ask this question in the internals
mail list.

Pros: more simple O(1) hash table checks for properties, functions,
methods, classes without strtolower normalization on the
engine/parser level. Consistency with unicode class names (yes, they
are case sensitive, check http://3v4l.org/ia0pc), consistency with
exisiting PSR0,4 standards (case sensitive mapping of class names to
the file names)

From my experience, all modern PHP framework don't use
case-insensitive code, so chance to break anything for them is
really low.

Cons: on the extension level things aren't so good and can be some
BC breaks (like with phpng)

Possible ways:

Keep PHP engine case-insensitive for PHP7

Make PHP engine case-sensitive since PHP7 with possible minor BC breaks
in the extensions (this breaks can be easily fixed)

Add a compile-time switch, eg. --with-case-sensitivity to the
configuration to have an ability to build PHP with sensitivity and make
this option enabled by default since next major version (PHP>=8.0). Add
deprecation notices in 7.x

INI switch is better. Compiler switch would not work well, since user
cannot check their code easily.

An INI setting that changes how syntax or code works is never never a
good idea. It's something that many developers have no control over.

To be really honest, I don't think all of the pro's hold up. For a hash
check, there is no change really - the only change that is to remove the
zend_tolower. Previous discussions have IIRC shown that the performance
benefit is minimal. Compatibility with PSR's is also a moot point, as
there are just recommendations.

However, there are a few extra cons: You are going to break
people's code on a large scale. I simply don't think it is worth it
(again, just like when this discussion popped up every year or so for
the last decade).

cheers,
Derick

9 years ago by Lester Caine — view source

unread

To be really honest, I don't think all of the pro's hold up. For a hash
check, there is no change really - the only change that is to remove the
zend_tolower. Previous discussions have IIRC shown that the performance
benefit is minimal. Compatibility with PSR's is also a moot point, as
there are just recommendations.

There is still the matter of 'internationalization', which is
technically a different RFC, but zend_tolower is only handling ASCII
character set? So modifying that function where appropriate may be
advantageous later.

However, there are a few extra cons: You are going to break
people's code on a large scale. I simply don't think it is worth it
(again, just like when this discussion popped up every year or so for
the last decade).

Having been stung by the 'cons' already in reverse when moving perfectly
stable code from windows to linux I'd actually say that it would have
been a 'pro' if the mixed case stuff that previous programmers had used
had been eliminated. I take a lot more care now ensuring that case IS
consistent and if PHP nannied this in the same way it nannies some other
style points, then I would put under the pro rather than con!

Some of the BC areas being discussed do seem 'why put us through that',
but unicode is still being pushed to the sidelines and this is one of
those BC breaks which would help pave the way for a clean unicode core
in the future.

--
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

9 years ago by francois@php.net — view source

unread

Hi Lester,

I agree. The only way I imagine possible (maybe Derick can confirm), is
adding an optional case-sensitive mode and, then, much later, make it the
default.

Unlike raising E_DEPRECATED on case-insensitive comparisons, this approach
is technically possible. The only probem I see is that people are shooting
down every new INI setting, whatever the need.

Regards

François

-----Message d'origine-----
De : Lester Caine [mailto:lester@lsces.co.uk]
Envoyé : mercredi 25 février 2015 11:04
À : internals@lists.php.net
Objet : Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

To be really honest, I don't think all of the pro's hold up. For a hash
check, there is no change really - the only change that is to remove the
zend_tolower. Previous discussions have IIRC shown that the performance
benefit is minimal. Compatibility with PSR's is also a moot point, as
there are just recommendations.

There is still the matter of 'internationalization', which is
technically a different RFC, but zend_tolower is only handling ASCII
character set? So modifying that function where appropriate may be
advantageous later.

However, there are a few extra cons: You are going to break
people's code on a large scale. I simply don't think it is worth it
(again, just like when this discussion popped up every year or so for
the last decade).

Having been stung by the 'cons' already in reverse when moving perfectly
stable code from windows to linux I'd actually say that it would have
been a 'pro' if the mixed case stuff that previous programmers had used
had been eliminated. I take a lot more care now ensuring that case IS
consistent and if PHP nannied this in the same way it nannies some other
style points, then I would put under the pro rather than con!

Some of the BC areas being discussed do seem 'why put us through that',
but unicode is still being pushed to the sidelines and this is one of
those BC breaks which would help pave the way for a clean unicode core
in the future.

--
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

9 years ago by Dmitry Stogov — view source

unread

Hi Alexander,

On Tue, Feb 24, 2015 at 10:48 AM, Alexander Lisachenko <
lisachenko.it@gmail.com> wrote:

Morning!

I want to ask this question one more time before PHP7 feature freeze: can
we the engine case sensitive from PHP>=7.0?

There is a draft for that: https://wiki.php.net/rfc/case-sensitivity
(mostly empty), so I decided to ask this question in the internals mail
list.

Pros: more simple O(1) hash table checks for properties, functions,
methods, classes without strtolower normalization on the engine/parser
level. Consistency with unicode class names (yes, they are case sensitive,
check http://3v4l.org/ia0pc), consistency with exisiting PSR0,4 standards
(case sensitive mapping of class names to the file names)

From my experience, all modern PHP framework don't use case-insensitive
code, so chance to break anything for them is really low.

Cons: on the extension level things aren't so good and can be some BC
breaks (like with phpng)

Possible ways:

Keep PHP engine case-insensitive for PHP7

Make PHP engine case-sensitive since PHP7 with possible minor BC breaks
in the extensions (this breaks can be easily fixed)

Add a compile-time switch, eg. --with-case-sensitivity to the
configuration to have an ability to build PHP with sensitivity and make
this option enabled by default since next major version (PHP>=8.0). Add
deprecation notices in 7.x

Thoughts?

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.

Thanks. Dmitry.

9 years ago by Pierre Joye — view source

unread

Hi Alexander,

On Tue, Feb 24, 2015 at 10:48 AM, Alexander Lisachenko <
lisachenko.it@gmail.com> wrote:

Morning!

I want to ask this question one more time before PHP7 feature freeze: can
we the engine case sensitive from PHP>=7.0?

There is a draft for that: https://wiki.php.net/rfc/case-sensitivity
(mostly empty), so I decided to ask this question in the internals mail
list.

Pros: more simple O(1) hash table checks for properties, functions,
methods, classes without strtolower normalization on the engine/parser
level. Consistency with unicode class names (yes, they are case sensitive,
check http://3v4l.org/ia0pc), consistency with exisiting PSR0,4 standards
(case sensitive mapping of class names to the file names)

From my experience, all modern PHP framework don't use case-insensitive
code, so chance to break anything for them is really low.

Cons: on the extension level things aren't so good and can be some BC
breaks (like with phpng)

Possible ways:

Keep PHP engine case-insensitive for PHP7

Make PHP engine case-sensitive since PHP7 with possible minor BC breaks
in the extensions (this breaks can be easily fixed)

Add a compile-time switch, eg. --with-case-sensitivity to the
configuration to have an ability to build PHP with sensitivity and make
this option enabled by default since next major version (PHP>=8.0). Add
deprecation notices in 7.x

Thoughts?

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.

--
Pierre

@pierrejoye | http://www.libgd.org

9 years ago by francois@php.net — view source

unread

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

9 years ago by Julien Pauli — view source

unread

Hi Alexander,

On Tue, Feb 24, 2015 at 10:48 AM, Alexander Lisachenko <
lisachenko.it@gmail.com> wrote:

Morning!

I want to ask this question one more time before PHP7 feature freeze: can
we the engine case sensitive from PHP>=7.0?

There is a draft for that: https://wiki.php.net/rfc/case-sensitivity
(mostly empty), so I decided to ask this question in the internals mail
list.

Pros: more simple O(1) hash table checks for properties, functions,
methods, classes without strtolower normalization on the engine/parser
level. Consistency with unicode class names (yes, they are case
sensitive,
check http://3v4l.org/ia0pc), consistency with exisiting PSR0,4
standards
(case sensitive mapping of class names to the file names)

From my experience, all modern PHP framework don't use case-insensitive
code, so chance to break anything for them is really low.

Cons: on the extension level things aren't so good and can be some BC
breaks (like with phpng)

Possible ways:

Keep PHP engine case-insensitive for PHP7

Make PHP engine case-sensitive since PHP7 with possible minor BC
breaks
in the extensions (this breaks can be easily fixed)

Add a compile-time switch, eg. --with-case-sensitivity to the
configuration to have an ability to build PHP with sensitivity and make
this option enabled by default since next major version (PHP>=8.0). Add
deprecation notices in 7.x

Thoughts?

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.

Thanks. Dmitry.

I agree that doesn't seem like a reasonable idea.

Julien.P

9 years ago by Robert Stoll — view source

unread

-----Ursprüngliche Nachricht-----
Von: julienpauli@gmail.com [mailto:julienpauli@gmail.com] Im Auftrag von Julien Pauli
Gesendet: Donnerstag, 26. Februar 2015 10:27
An: Dmitry Stogov
Cc: Alexander Lisachenko; PHP internals list
Betreff: Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

Hi Alexander,

On Tue, Feb 24, 2015 at 10:48 AM, Alexander Lisachenko <
lisachenko.it@gmail.com> wrote:

Morning!

I want to ask this question one more time before PHP7 feature
freeze: can we the engine case sensitive from PHP>=7.0?

There is a draft for that: https://wiki.php.net/rfc/case-sensitivity
(mostly empty), so I decided to ask this question in the internals
mail list.

Pros: more simple O(1) hash table checks for properties, functions,
methods, classes without strtolower normalization on the
engine/parser level. Consistency with unicode class names (yes, they
are case
sensitive,
check http://3v4l.org/ia0pc), consistency with exisiting PSR0,4
standards
(case sensitive mapping of class names to the file names)

From my experience, all modern PHP framework don't use
case-insensitive code, so chance to break anything for them is really low.

Cons: on the extension level things aren't so good and can be some
BC breaks (like with phpng)

Possible ways:

Keep PHP engine case-insensitive for PHP7

Make PHP engine case-sensitive since PHP7 with possible minor BC
breaks
in the extensions (this breaks can be easily fixed)

Add a compile-time switch, eg. --with-case-sensitivity to the
configuration to have an ability to build PHP with sensitivity and
make this option enabled by default since next major version
(PHP>=8.0). Add deprecation notices in 7.x

Thoughts?

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.

Thanks. Dmitry.

I agree that doesn't seem like a reasonable idea.

Julien.P

I also agree, I think that is something for a static code analyser to rant about

[Discussion] Last chance for case-sensitive engine

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL