Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] Deprecate and remove case-insensitive constants?

Posted by Christoph M. Becker 
Lester Caine
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 02:40PM
On 14/09/17 10:20, Tony Marston wrote:
> Then unix came along and FUBAR'd everything. Any advantages of case
> sensitive systems are ALWAYS outweighed by their disadvantages.

Unix predates Windows ... the use of such breaks as having spaces in
file names came from that development in addition to the line ending.
The RTTY machines needed a carriage return step followed by a line feed
which is why that was two steps initially. Not needed these days, but
still embeded from the early days.

UTF8 introduces a level of complexity and can be used used in many
places in PHP, but it does seem that there is no drive these days to
make the core a clean UTF8 environment. This should perhaps be addressed
again for PHP8? But the additional problems that case-insensitive then
introduces may mean that all case-insensitivity has to be removed at
that point?

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 03:10PM
"Daniel Morris" wrote in message
news:[email protected]om...
>
>On Thu, 14 Sep 2017, at 10:20 AM, Tony Marston wrote:
>> If the first programming languages in the first computers were case
>> insensitive, then that should be the standard. Those who introduced case
>> sensitive languages at a later date should be forced to justify that
>> decision.
>
>If the first vehicles had two wheels, then that should be the standard.
>Those who introduced cars with four wheels should be forced to justify
>that decision.
>
>If the first television was black and white, then that should be the
>standard. Those who introduced televisions with colour should be forced
>to justify that decision.
>
>If the first living organisms had single cells, then that should be the
>standard. Evolution should be forced to justify the decision to move to
>multiple cells.
>
>If light exists as a wave, then that should be the standard. When an
>observer collapses the wave function, then they should be forced to
>justify that decision.
>
>--
>Daniel Morris
>[email protected]

You are being deliberately awkward. While things can progress, change,
improve and be added to over time, I can see no justification for removing a
facility or capability just for the convenience of a miniscule number of
developers. Just because the first Ford motor cars were black is no
justification for saying that all cars should be black. The idea that all
cars should have their ability to steer around bends be removed just because
the car makers find it easier to build cars that can only run in straight
lines would be just plain nonsense.

Introducing case sensitivity into what is mostly a case-insensitive world
just for the convenience of a few programmers I do not consider to be
acceptable. It would cause more problems for far more people than the
insignificant few who insist on using obscure character sets. Why should the
English-speaking world be forced to suffer just because some minor languages
cannot handle case folding?

If the problem has already been solved with UTF8 then no other solution
should be required. If the support for UTF8 needs to be enhanced in PHP then
enhance it. Do not remove case-insensitive software just because it is
"convenient".

As was said in a Star Trek movie - the needs of the many outweigh the needs
of the few.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Michael Morris
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 03:20PM
On Thu, Sep 14, 2017 at 8:33 AM, Lester Caine <[email protected]> wrote:

> UTF8 introduces a level of complexity and can be used used in many
> places in PHP, but it does seem that there is no drive these days to
> make the core a clean UTF8 environment. This should perhaps be addressed
> again for PHP8?
>
>
*Cough*, *Cough*, PHP 6, *Cough*, *Cough*.

Comedy aside, Full UTF functionality was planned for PHP 6 and ended up
sinking the branch because it was way more complicated that anyone realized
at first. Someone involved with the development at that time can speak to
it more accurately - all I know is hearsay and conjecture.
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 03:20PM
"Lester Caine" wrote in message
news:[email protected]
>
>On 14/09/17 10:20, Tony Marston wrote:
>> Then unix came along and FUBAR'd everything. Any advantages of case
>> sensitive systems are ALWAYS outweighed by their disadvantages.
>
>Unix predates Windows ...

A minor detail. Windows followed all the previous OSes which I had used in
being case insensitive, which makes unix the odd one out. Besides there are
far more computers running Windows than unix, so unixx should not be used as
the standard.

> the use of such breaks as having spaces in
>file names came from that development in addition to the line ending.
>The RTTY machines needed a carriage return step followed by a line feed
>which is why that was two steps initially. Not needed these days, but
>still embeded from the early days.

I also saw LF and CR being used independently in a driver for a daisywheel
printer in the 1970s.

The fact that both CR and LF are not needed these days should have been
addressed by a common solution used by all OSes, and not each OS using a
different solution.

>UTF8 introduces a level of complexity and can be used used in many
>places in PHP, but it does seem that there is no drive these days to
>make the core a clean UTF8 environment. This should perhaps be addressed
>again for PHP8?

If UTF8 solves the problem, but has yet to be properly implemented in PHP,
then the PHP implementation should be addressed.

> But the additional problems that case-insensitive then
>introduces may mean that all case-insensitivity has to be removed at
>that point?

What additional problems? When billions of people are used to living in a
case-insensitive world and the only "problems" affect an insignificantly
small number in an insignificantly small number of circumstances then the
only proper solution is one that solves the problem for the small number
without messing it up for the far larger number.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 03:30PM
On 14.09.2017 at 14:59, Tony Marston wrote:

> Introducing case sensitivity into what is mostly a case-insensitive
> world just for the convenience of a few programmers I do not consider to
> be acceptable. It would cause more problems for far more people than the
> insignificant few who insist on using obscure character sets. Why should
> the English-speaking world be forced to suffer just because some minor
> languages cannot handle case folding?

This is not about an "insignificant few who insist on using obscure
character sets", but rather about a language spoken by millions of
people which has to "I" characters, namely dotted and dotless "I".
Rather consistently, the dotless "I"'s lower-case variant is "ı", and
the dotted "İ"'s lower-case variant is "i". There you go.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 03:30PM
On 14 September 2017 13:59:20 BST, Tony Marston <[email protected]> wrote:
> Why should the
>English-speaking world be forced to suffer just because some minor
>languages
>cannot handle case folding?

Have you any idea how arrogant this sounds? Why should "the English-speaking world" get to make up the rules? What criteria make something "a minor language"? Who gave you the right to make such lofty pronouncements?

And, please, stop muddling UTF8, a particular way of representing text in binary, with Unicode, the huge and complex standard that attempts to handle fairly these "minor languages" which you dismiss so casually. Or preferably just stop commenting on topics you so obviously don't understand.

Regards,

--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 03:40PM
On 14/09/17 14:10, Michael Morris wrote:
> On Thu, Sep 14, 2017 at 8:33 AM, Lester Caine <[email protected]> wrote:
>
>> UTF8 introduces a level of complexity and can be used used in many
>> places in PHP, but it does seem that there is no drive these days to
>> make the core a clean UTF8 environment. This should perhaps be addressed
>> again for PHP8?
>>
> *Cough*, *Cough*, PHP 6, *Cough*, *Cough*.
>
> Comedy aside, Full UTF functionality was planned for PHP 6 and ended up
> sinking the branch because it was way more complicated that anyone realized
> at first. Someone involved with the development at that time can speak to
> it more accurately - all I know is hearsay and conjecture.

My point exactly ...

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 03:40PM
""Christoph M. Becker"" wrote in message
news:[email protected]
>
>On 14.09.2017 at 14:59, Tony Marston wrote:
>
>> Introducing case sensitivity into what is mostly a case-insensitive
>> world just for the convenience of a few programmers I do not consider to
>> be acceptable. It would cause more problems for far more people than the
>> insignificant few who insist on using obscure character sets. Why should
>> the English-speaking world be forced to suffer just because some minor
>> languages cannot handle case folding?
>
>This is not about an "insignificant few who insist on using obscure
>character sets", but rather about a language spoken by millions of
>people which has to "I" characters, namely dotted and dotless "I".
>Rather consistently, the dotless "I"'s lower-case variant is "i", and
>the dotted "I"'s lower-case variant is "i". There you go.
>

The number of people in the world who use character sets which do not have
this problem far outnumber those who use character sets which do have this
problem. People without this problem far outnumber the others, so it would
not be a good idea to inconvenience the many just to satisfy the few.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Alain Williams
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 03:50PM
On Thu, Sep 14, 2017 at 02:16:47PM +0100, Tony Marston wrote:

> A minor detail. Windows followed all the previous OSes which I had
> used in being case insensitive, which makes unix the odd one out.
> Besides there are far more computers running Windows than unix, so
> unixx should not be used as the standard.

So you want a return to the horrors of code pages in file systems ? Ie how you
map lower -> upper depends on how you encode characters. Far better that that
problem is taken away from the file system (which should be clean, robust and
fast) and if you want case independence put it up at the application layer.

I vote for making it case sensitive: simpler for the parser; the programmer
rapidly learns that it should be 'TRUE' and not 'true' -- job done.

This is what Javascript does.

Many operating systems were case insensitive since your input terminal (eg AR33
Teletype) could only generate one case. But in those days it was simple since
you only had one character set: ASCII or EBCDIC (translation of alphabetics
between the 2 was easy, some others not so, eg: @"\£#).

> >But the additional problems that case-insensitive then
> >introduces may mean that all case-insensitivity has to be removed at
> >that point?
>
> What additional problems? When billions of people are used to living
> in a case-insensitive world and the only "problems" affect an
> insignificantly small number in an insignificantly small number of
> circumstances then the only proper solution is one that solves the
> problem for the small number without messing it up for the far
> larger number.

That is the sort of mind-set that results in browsers accepting all sort of
broken markup and making guesses on what is intended; different browsers make
different guesses and render the page differently. The user then blames browser
X for getting it wrong rather than the incompetent web developer who can't be
bothered to check that their markup is correct.

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Alain Williams
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 03:50PM
On Thu, Sep 14, 2017 at 02:36:27PM +0100, Tony Marston wrote:
> ""Christoph M. Becker"" wrote in message
> news:[email protected]
> >
> >On 14.09.2017 at 14:59, Tony Marston wrote:
> >
> >>Introducing case sensitivity into what is mostly a case-insensitive
> >>world just for the convenience of a few programmers I do not consider to
> >>be acceptable. It would cause more problems for far more people than the
> >>insignificant few who insist on using obscure character sets. Why should
> >>the English-speaking world be forced to suffer just because some minor
> >>languages cannot handle case folding?
> >
> >This is not about an "insignificant few who insist on using obscure
> >character sets", but rather about a language spoken by millions of
> >people which has to "I" characters, namely dotted and dotless "I".
> >Rather consistently, the dotless "I"'s lower-case variant is "i", and
> >the dotted "I"'s lower-case variant is "i". There you go.
> >
>
> The number of people in the world who use character sets which do
> not have this problem far outnumber those who use character sets
> which do have this problem. People without this problem far
> outnumber the others, so it would not be a good idea to
> inconvenience the many just to satisfy the few.

Translation: I do not use these character sets, those who do are not important.

PHP (& File systems) are best staying away from things like that. Not attempting
case folding, and similar, makes it simpler, faster & more robust (not worrying
about what sort of 'i' to convert to). It only helps those who do not know what
the SHIFT key is for.

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 03:50PM
"Rowan Collins" wrote in message
news:[email protected]
>
>On 14 September 2017 13:59:20 BST, Tony Marston <[email protected]>
>wrote:
>> Why should the
>>English-speaking world be forced to suffer just because some minor
>>languages
>>cannot handle case folding?
>
>Have you any idea how arrogant this sounds? Why should "the
>English-speaking world" get to make up the rules? What criteria make
>something "a minor language"? Who gave you the right to make such lofty
>pronouncements?

Because the English-speaking world invented both computers and the languages
used to program them. The early ASCII character set supported only the
English/American languages, and while other languages were supported on an
ad hoc basis with specific character sets, the creation of a single UNICODE
standard to cover all possible character sets was later created and should
be available in all languages. If UNICODE solves all particular issues
regarding case-insensitive software, but has yet to be properly implemented
in PHP, then the correct response to this problem would be to rectify PHP's
implementation.

>And, please, stop muddling UTF8, a particular way of representing text in
>binary, with Unicode, the huge and complex standard that attempts to handle
>fairly these "minor languages" which you dismiss so casually. Or preferably
>just stop commenting on topics you so obviously don't understand.

The terms "UTF8" and "UNICODE" do not mean entirely different things. The
page at https://en.wikipedia.org/wiki/UTF-8 speaks of "UTF-8-encoded
Unicode", so for may people they are just different sides of the same coin.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 04:00PM
On Tue, Sep 12, 2017 at 8:02 PM, Christoph M. Becker <[email protected]>
wrote:

> Hi everybody!
>
> Usually constant identifiers are treated case-sensitive in PHP. This is
> always the case for constants defined via a `const` declaration.
> However, define() allows to pass TRUE as third argument to define a
> case-insensitive constant. This feature appears to potentially result
> in confusion, and also causes bugs as shown in
> https://bugs.php.net/74450. See an example created by Nikita to see
> some probably unexpected behavior: https://3v4l.org/L6nCp.
>
> Even if these issues could be resolved, I still think allowing both
> case-sensitive and case-insensitive constant identifiers does more harm
> than good, so either case-sensitive or case-insensitive constant
> identifiers should be removed from the language. Since case-sensitive
> constant identifiers are already the default, and HHVM doesn't even
> support case-insensitive identifiers at all, I would suggest to remove
> case-insensitive constant identifiers.
>
> This could be implemented by triggering E_DEPRECATED whenever the third
> argument to define() is TRUE in PHP 7.3, and to remove this parameter
> altogether in PHP 8. Most likely some further simplification in the
> engine could be done then as well.
>
> Thoughts?
>

+1 on doing this. I can understand having case-insensitive constants, but
having both case-sensitive and case-insensitive at the same time is weird
and rather useless. I imagine the only reason why this "feature" exists in
the first place is to support arbitrary casing for true/false/null, which
is better handled by special-casing these particular constants (something
we already do for various other reasons). This will simplify the language,
reduce implementation complexity on our side and resolve some bugs that are
infeasible to fix otherwise.

Nikita
Alain Williams
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 04:00PM
On Thu, Sep 14, 2017 at 02:48:06PM +0100, Tony Marston wrote:
> "Rowan Collins" wrote in message
> news:[email protected]
> >
> >On 14 September 2017 13:59:20 BST, Tony Marston
> ><[email protected]> wrote:
> >>Why should the
> >>English-speaking world be forced to suffer just because some minor
> >>languages
> >>cannot handle case folding?
> >
> >Have you any idea how arrogant this sounds? Why should "the
> >English-speaking world" get to make up the rules? What criteria
> >make something "a minor language"? Who gave you the right to make
> >such lofty pronouncements?
>
> Because the English-speaking world invented both computers and the
> languages used to program them.

The light bulb was invented by an English man (Joseph Swan), the television by a
Scott (John Logie Baird); so should the Brits and Scots be the ones that define
light bulb and TV standards to suit their convenience ?

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Daniel Morris
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 04:10PM
On Thu, 14 Sep 2017, at 02:48 PM, Tony Marston wrote:
> Because the English-speaking world invented both computers and the
> languages used to program them.

It was a German that invented binary, so my suggestion is to devolve all
future decisions to the Germans.

On Thu, 14 Sep 2017, at 02:36 PM, Tony Marston wrote:
> The number of people in the world who use character sets which do
> not have this problem far outnumber those who use character sets
> which do have this problem. People without this problem far
> outnumber the others, so it would not be a good idea to
> inconvenience the many just to satisfy the few.

You are nearly always a minority opinion, the irony of you writing this
whilst at the same time asking the world to slow down so that your
stubborn fourteen year old framework can catch up beggars belief.

--
Daniel Morris
daniel@honestempire.com


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
François Laupretre
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 05:40PM
Le 14/09/2017 à 15:38, Alain Williams a écrit :
> I vote for making it case sensitive: simpler for the parser; the
> programmer
> rapidly learns that it should be 'TRUE' and not 'true' -- job done.

No need to force people to switch their code to 'TRUE'. Just supporting
case-sensitive 'TRUE', 'true', and 'True' (the same for false and null)
should be enough. Not supporting 'tRUE' or 'TrUe' anymore will also be a
positive side effect for code readability.

Regards

François


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 05:50PM
On Tue, Sep 12, 2017 at 8:02 AM, Christoph M. Becker <[email protected]> wrote:
> Usually constant identifiers are treated case-sensitive in PHP. This is
> always the case for constants defined via a `const` declaration.
> However, define() allows to pass TRUE as third argument to define a
> case-insensitive constant. This feature appears to potentially result
> in confusion, and also causes bugs as shown in
> https://bugs.php.net/74450. See an example created by Nikita to see
> some probably unexpected behavior: https://3v4l.org/L6nCp.
>
I'd just like to ask everyone on this thread to circle back to the
actual topic: Case-Insensitive Constants. Nothing else is on topic
here. If you'd like to argue the value of Turkish case folding and
its impact on combined symbol tables in 40 year old software, I
encourage you to start a new thread for that topic.

Of the minority of responses to this thread reflecting on the actual
goal of the proposal, I've seen responses from "sure, why not?" to
"what's the point?", but if there was a coherent argument firmly
against, I must have missed it.

So could we focus on the topic at hand, please?

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 05:50PM
On Thu, Sep 14, 2017 at 11:37 AM, François Laupretre
<[email protected]> wrote:
> Le 14/09/2017 à 15:38, Alain Williams a écrit :
>>
>> I vote for making it case sensitive: simpler for the parser; the
>> programmer
>> rapidly learns that it should be 'TRUE' and not 'true' -- job done.
>
>
> No need to force people to switch their code to 'TRUE'. Just supporting
> case-sensitive 'TRUE', 'true', and 'True' (the same for false and null)
> should be enough. Not supporting 'tRUE' or 'TrUe' anymore will also be a
> positive side effect for code readability.
>
+0.9 this. It feels pretty simple to resolve this special-case for
case-sensitivity at any stage of the compile, but the reality is that
TRUE/True/true covers 99% of uses, and a static analyzer can
*trivially* find those other cases prior to an upgrade. Heck, 3
minutes with a token_get_all() script can find 'em, even produce a
rewrite diff if you're so inclined.

Nevermind, make that +1. The ease of auditing mixed-case uses makes
supporting it in the compiler not worth the maintenance.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Levi Morrison
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 06:10PM
On Thu, Sep 14, 2017 at 9:38 AM, Sara Golemon <[email protected]> wrote:
> On Tue, Sep 12, 2017 at 8:02 AM, Christoph M. Becker <[email protected]> wrote:
>> Usually constant identifiers are treated case-sensitive in PHP. This is
>> always the case for constants defined via a `const` declaration.
>> However, define() allows to pass TRUE as third argument to define a
>> case-insensitive constant. This feature appears to potentially result
>> in confusion, and also causes bugs as shown in
>> https://bugs.php.net/74450. See an example created by Nikita to see
>> some probably unexpected behavior: https://3v4l.org/L6nCp.
>>
> I'd just like to ask everyone on this thread to circle back to the
> actual topic: Case-Insensitive Constants. Nothing else is on topic
> here. If you'd like to argue the value of Turkish case folding and
> its impact on combined symbol tables in 40 year old software, I
> encourage you to start a new thread for that topic.
>
> Of the minority of responses to this thread reflecting on the actual
> goal of the proposal, I've seen responses from "sure, why not?" to
> "what's the point?", but if there was a coherent argument firmly
> against, I must have missed it.
>
> So could we focus on the topic at hand, please?

For what it is worth the Turkish locale issue is on-topic. If we have
case sensitivity and case insensitivity simultaneously in constants
and we decide to drop one then the locale issue points towards
dropping case insensitivity.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 06:30PM
On 14.09.2017 at 17:37, François Laupretre wrote:

> Le 14/09/2017 à 15:38, Alain Williams a écrit :
>
>> I vote for making it case sensitive: simpler for the parser; the
>> programmer
>> rapidly learns that it should be 'TRUE' and not 'true' -- job done.
>
> No need to force people to switch their code to 'TRUE'. Just supporting
> case-sensitive 'TRUE', 'true', and 'True' (the same for false and null)
> should be enough. Not supporting 'tRUE' or 'TrUe' anymore will also be a
> positive side effect for code readability.

I'd rather not introduce a special case here. All PHP keywords are
currently case-insensitive (CMIIW), so promoting true, false and null
from reserved words to keywords would solve this issue: all constants
are case-sensitive, all keywords are case-insensitive, the latter
obviously taking precedence. And frankly, if somebody really prefers to
write "TruE", why bother? This would still be far from having a chance
to win a "most obfuscated code contest".

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 08:30PM
On Thu, Sep 14, 2017 at 12:02 PM, Levi Morrison <[email protected]> wrote:
> On Thu, Sep 14, 2017 at 9:38 AM, Sara Golemon <[email protected]> wrote:
>> On Tue, Sep 12, 2017 at 8:02 AM, Christoph M. Becker <[email protected]> wrote:
>>> Usually constant identifiers are treated case-sensitive in PHP. This is
>>> always the case for constants defined via a `const` declaration.
>>> However, define() allows to pass TRUE as third argument to define a
>>> case-insensitive constant. This feature appears to potentially result
>>> in confusion, and also causes bugs as shown in
>>> https://bugs.php.net/74450. See an example created by Nikita to see
>>> some probably unexpected behavior: https://3v4l.org/L6nCp.
>>>
>> I'd just like to ask everyone on this thread to circle back to the
>> actual topic: Case-Insensitive Constants. Nothing else is on topic
>> here. If you'd like to argue the value of Turkish case folding and
>> its impact on combined symbol tables in 40 year old software, I
>> encourage you to start a new thread for that topic.
>>
>> Of the minority of responses to this thread reflecting on the actual
>> goal of the proposal, I've seen responses from "sure, why not?" to
>> "what's the point?", but if there was a coherent argument firmly
>> against, I must have missed it.
>>
>> So could we focus on the topic at hand, please?
>
> For what it is worth the Turkish locale issue is on-topic. If we have
> case sensitivity and case insensitivity simultaneously in constants
> and we decide to drop one then the locale issue points towards
> dropping case insensitivity.
>
Except that we don't actually support case-insensitive constants and
never have. We support ASCII case-insensitivity. Of course, this
supports your "let's drop case insensitivity" position on the grounds
that our implementation of it is ironically parochial and terrible.

The argument about Turkish becomes irrelevant though since any
constant declared with a non-english identifier is (at least
partially) forced to be case-sensitive by virtue of our non-localized
tolower implementation.

https://3v4l.org/Od03d

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 14, 2017 11:30PM
Hi!

> +1 on doing this. I can understand having case-insensitive constants, but
> having both case-sensitive and case-insensitive at the same time is weird
> and rather useless. I imagine the only reason why this "feature" exists in
> the first place is to support arbitrary casing for true/false/null, which
> is better handled by special-casing these particular constants (something
> we already do for various other reasons). This will simplify the language

If we support all case-insensitive constants that are predefined (not
sure if any exts do that but we have to support those too if they do)
then I don't see a big problem in phasing-out user-defined ones.

After a quick gihub scan, I see there's some usage of case-insensitive
constants but most of it doesn't seem to be actually using that thing
(i.e. usages are in the same case as definition).

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 01:00AM
On 14.09.2017 at 23:22, Stanislav Malyshev wrote:

> [Nikita wrote]
>
>> +1 on doing this. I can understand having case-insensitive constants, but
>> having both case-sensitive and case-insensitive at the same time is weird
>> and rather useless. I imagine the only reason why this "feature" exists in
>> the first place is to support arbitrary casing for true/false/null, which
>> is better handled by special-casing these particular constants (something
>> we already do for various other reasons). This will simplify the language
>
> If we support all case-insensitive constants that are predefined (not
> sure if any exts do that but we have to support those too if they do)
> then I don't see a big problem in phasing-out user-defined ones.

It seems to me that this would miss the point, namely to introduce some
consistency, and to be able to

> [Nikita continued]
>
>> reduce implementation complexity on our side and resolve some bugs
>> that are infeasible to fix otherwise.

All programming languages that I know of are either case-sensitive or
case-insensitive. PHP is the sole execption (CMIIW) – and the potential
cognitive overhead during programming is hard to justify. Constants are
the icing on the cake: they can be either case-insensitive or
case-sensitive at the discression of the dev defining the constant.
Using an extension which defines case-insensitive constants might raise
the following issue:

<?php
define('FOO', true, true); // public const in ext; transcript from C
const FOO = false; // in global app code

Why doesn't that fail? How am I supposed to write the extension
constant afterwards? Ah, yes, `foo`, of course! The PHP manual
explains that quite clearly, so there must be a bug in my IDE and the
docs of the extension. Oh, it's home time – I'm going to enjoy a nice
evening reading Brainf*ck code… ;)

FTR: there are 2811 occurances of REGISTER_\w+\_CONSTANT in current
php-src master, all of which use CONST_CS. phpinternalsbook.com
mentions succinctly:

| The flags are mixed OR operation between CONST_CS (case-sensitive
| constant, what we want), […]

I completely fail to see why we should retain the possibility to define
case-insensitive constants in extensions. Deprecate that for PHP 7.3.0
(which is more than a year away) and remove in PHP 8.0.0 (which might be
several years away) seems to be acceptable. IMHO we should strive to
remove accidental complexity as soon as possible (and clearly, this is
not essential complexity).

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 01:40AM
Hi!

> It seems to me that this would miss the point, namely to introduce some
> consistency, and to be able to

If working code would be broken, nobody needs "consistency". I've built
tons of software, and never ever any single client asked me "but do you
have 'constistency'? Surely, I'm not against that warm fuzzy feeling
that some call "consistency", but not at the expense of breaking working
code.

> All programming languages that I know of are either case-sensitive or
> case-insensitive. PHP is the sole execption (CMIIW) – and the potential
> cognitive overhead during programming is hard to justify. Constants are

Would be very good argument if we were designing a new language called
"PHP". Unfortunately, we're about 20 years late to that. When we design
the next one, we'd be sure to take it into the account. For this one,
not breaking people's working code is IMO a much bigger and more useful
concern.

> <?php
> define('FOO', true, true); // public const in ext; transcript from C
> const FOO = false; // in global app code
>
> Why doesn't that fail? How am I supposed to write the extension

It should fail, but that's not what we're discussing here.

> I completely fail to see why we should retain the possibility to define
> case-insensitive constants in extensions. Deprecate that for PHP 7.3.0

We probably should not, but we should keep the ones that were there, if
they were. If you say that everybody already used CONST_CS then great. I
see however that some extensions (e.g. ibase and mcrypt) do not use that
flag.
--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 11:00AM
"Alain Williams" wrote in message
news:[email protected]
>
>On Thu, Sep 14, 2017 at 02:16:47PM +0100, Tony Marston wrote:
>
>> A minor detail. Windows followed all the previous OSes which I had
>> used in being case insensitive, which makes unix the odd one out.
>> Besides there are far more computers running Windows than unix, so
>> unixx should not be used as the standard.
>
>So you want a return to the horrors of code pages in file systems ?

I never said that.

> Iike how you map lower -> upper depends on how you encode characters.

Then use a single UNICODE character set where every character has both an
upper and lower case representation. Problem solved.

> Far better that that
>problem is taken away from the file system (which should be clean, robust
>and
>fast) and if you want case independence put it up at the application layer.

You try telling that to the billions of Windows users who have been used to
a case insensitive file system for decades. Not to mention all Microsoft
software which is case insensitive. Try to take that away and billions of
users will be baying for your blood.

>I vote for making it case sensitive: simpler for the parser; the programmer
>rapidly learns that it should be 'TRUE' and not 'true' -- job done.
>
>This is what Javascript does.

I don't give two hoots what javascript does.

>Many operating systems were case insensitive since your input terminal (eg
>AR33
>Teletype) could only generate one case. But in those days it was simple
>since
>you only had one character set: ASCII or EBCDIC (translation of alphabetics
>between the 2 was easy, some others not so, eg: @"\£#).
>
>> >But the additional problems that case-insensitive then
>> >introduces may mean that all case-insensitivity has to be removed at
>> >that point?
>>
>> What additional problems? When billions of people are used to living
>> in a case-insensitive world and the only "problems" affect an
>> insignificantly small number in an insignificantly small number of
>> circumstances then the only proper solution is one that solves the
>> problem for the small number without messing it up for the far
>> larger number.

>That is the sort of mind-set that results in browsers accepting all sort of
>broken markup and making guesses on what is intended; different browsers
>make
>different guesses and render the page differently. The user then blames
>browser
>X for getting it wrong rather than the incompetent web developer who can't
>be
>bothered to check that their markup is correct.

UNICODE was supposedly invented to deal with all these problems so why
doesn't it? Why is it not possible to define an uppercase and lowercase
variant of the same character? If the problem lies with an incomplete
implementation of UNICODE then that is the problem which should be
addressed. Any programmer who says that he doesn't have the brain power to
provide a proper solution and proposes instead to remove case insensitivity
from the entire universe "because it is more convenient" should hang his
head in shame. It is the programmer's job to make things easier and more
convenient for the user, not for users to accept what is convenient for the
programmers to provide.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 11:10AM
"Alain Williams" wrote in message
news:[email protected]
>
>On Thu, Sep 14, 2017 at 02:36:27PM +0100, Tony Marston wrote:
>> ""Christoph M. Becker"" wrote in message
>> news:[email protected]
>> >
>> >On 14.09.2017 at 14:59, Tony Marston wrote:
>> >
>> >>Introducing case sensitivity into what is mostly a case-insensitive
>> >>world just for the convenience of a few programmers I do not consider
>> >>to
>> >>be acceptable. It would cause more problems for far more people than
>> >>the
>> >>insignificant few who insist on using obscure character sets. Why
>> >>should
>> >>the English-speaking world be forced to suffer just because some minor
>> >>languages cannot handle case folding?
>> >
>> >This is not about an "insignificant few who insist on using obscure
>> >character sets", but rather about a language spoken by millions of
>> >people which has to "I" characters, namely dotted and dotless "I".
>> >Rather consistently, the dotless "I"'s lower-case variant is "i", and
>> >the dotted "I"'s lower-case variant is "i". There you go.
>> >
>>
>> The number of people in the world who use character sets which do
>> not have this problem far outnumber those who use character sets
>> which do have this problem. People without this problem far
>> outnumber the others, so it would not be a good idea to
>> inconvenience the many just to satisfy the few.
>
>Translation: I do not use these character sets, those who do are not
>important.

Incorrect. The proper question is: How any character sets have this problem?
What percentage of the world's computer users are affected by this problem?
If this number is quite small then it would be wrong to make the majority
suffer just because you don't know how to fix the problem that affects the
minority.

>PHP (& File systems) are best staying away from things like that.

Microsoft produces case insensitive software, including file systems,
because that is what users are used to. Unix was invented in a laboratory by
academics who couldn't develop case insensitive software so they called it a
"feature" and not a "bug".

> Not attempting
>case folding, and similar, makes it simpler, faster & more robust (not
>worrying
>about what sort of 'i' to convert to). It only helps those who do not know
>what
>the SHIFT key is for.

Why is it not possible to identify a single upper and lower case variant for
every character in every character set?

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 11:10AM
"Alain Williams" wrote in message
news:[email protected]
>
>On Thu, Sep 14, 2017 at 02:48:06PM +0100, Tony Marston wrote:
>> "Rowan Collins" wrote in message
>> news:[email protected]
>> >
>> >On 14 September 2017 13:59:20 BST, Tony Marston
>> ><TonyMarst[email protected]> wrote:
>> >>Why should the
>> >>English-speaking world be forced to suffer just because some minor
>> >>languages
>> >>cannot handle case folding?
>> >
>> >Have you any idea how arrogant this sounds? Why should "the
>> >English-speaking world" get to make up the rules? What criteria
>> >make something "a minor language"? Who gave you the right to make
>> >such lofty pronouncements?
>>
>> Because the English-speaking world invented both computers and the
>> languages used to program them.
>
>The light bulb was invented by an English man (Joseph Swan), the television
>by a
>Scott (John Logie Baird); so should the Brits and Scots be the ones that
>define
>light bulb and TV standards to suit their convenience ?
>

Don't be silly. Neither light bulbs nor television sets are affected by
which case is used in which character set.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 11:20AM
"Daniel Morris" wrote in message
news:[email protected]om...
>
>On Thu, 14 Sep 2017, at 02:48 PM, Tony Marston wrote:
>> Because the English-speaking world invented both computers and the
>> languages used to program them.
>
>It was a German that invented binary, so my suggestion is to devolve all
>future decisions to the Germans.

Binary coding is not affected by changes in case so this argument is bogus.

>On Thu, 14 Sep 2017, at 02:36 PM, Tony Marston wrote:
>> The number of people in the world who use character sets which do
>> not have this problem far outnumber those who use character sets
>> which do have this problem. People without this problem far
>> outnumber the others, so it would not be a good idea to
>> inconvenience the many just to satisfy the few.
>
>You are nearly always a minority opinion, the irony of you writing this
>whilst at the same time asking the world to slow down so that your
>stubborn fourteen year old framework can catch up beggars belief.

I am not asking the world to slow down because I am too lazy to change. I am
arguing that case insensitive software has been around for many decades, and
for some people to advocate for its removal just because they don't have the
brain power to come up with a proper solution for a minor glitch that
affects only a small number of languages I find unacceptable. A competent
programmer would fix the problem that affects the few without removing a
feature that the many are used to.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andrey Andreev
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 11:20AM
Hi,

On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston <[email protected]> wrote:
>
>> Far better that that
>> problem is taken away from the file system (which should be clean, robust
>> and
>> fast) and if you want case independence put it up at the application
>> layer.
>
>
> You try telling that to the billions of Windows users who have been used to
> a case insensitive file system for decades. Not to mention all Microsoft
> software which is case insensitive. Try to take that away and billions of
> users will be baying for your blood.
>

Billions? Do we have that statistic available?
And how many of them have ever encountered case-sensitivity as a concept?
Do they all manually type-in filenames that they want to open? If so,
do they for some reason name their files in all upper-case, but then
type in lower-case while opening?
Also, are we Microsoft developers? Are we trying to change Windows?

And most importantly: How do everyday Windows users have anything to
do with PHP developers?

Cheers,
Andrey.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Alain Williams
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 11:30AM
On Fri, Sep 15, 2017 at 10:04:51AM +0100, Tony Marston wrote:

> >The light bulb was invented by an English man (Joseph Swan), the
> >television by a
> >Scott (John Logie Baird); so should the Brits and Scots be the
> >ones that define
> >light bulb and TV standards to suit their convenience ?
> >
>
> Don't be silly. Neither light bulbs nor television sets are affected
> by which case is used in which character set.


> >>Because the English-speaking world invented both computers and the
> >>languages used to program them.
> >
> >It was a German that invented binary, so my suggestion is to devolve all
> >future decisions to the Germans.
>
> Binary coding is not affected by changes in case so this argument is bogus.


I think that both Rowan Collins & I agree on that point. We were commenting on
your assertion:

> >>Because the English-speaking world invented both computers and the
> >>languages used to program them.
> >

Thus because we are English speaking we do not have a special position to
dictate the development of computers and languages -- especially as it affects
non-English speakers.

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 11:30AM
""Christoph M. Becker"" wrote in message
news:[email protected]
>
>On 14.09.2017 at 23:22, Stanislav Malyshev wrote:
>
>> [Nikita wrote]
>>
>>> +1 on doing this. I can understand having case-insensitive constants,
>>> but
>>> having both case-sensitive and case-insensitive at the same time is
>>> weird
>>> and rather useless. I imagine the only reason why this "feature" exists
>>> in
>>> the first place is to support arbitrary casing for true/false/null,
>>> which
>>> is better handled by special-casing these particular constants
>>> (something
>>> we already do for various other reasons). This will simplify the
>>> language
>>
>> If we support all case-insensitive constants that are predefined (not
>> sure if any exts do that but we have to support those too if they do)
>> then I don't see a big problem in phasing-out user-defined ones.
>
>It seems to me that this would miss the point, namely to introduce some
>consistency, and to be able to
>
>> [Nikita continued]
>>
>>> reduce implementation complexity on our side and resolve some bugs
>>> that are infeasible to fix otherwise.
>
>All programming languages that I know of are either case-sensitive or
>case-insensitive.

You are missing a third option - Microsoft languages are case-preserving.
This is where the IDE ensures that every use of a word is automatically
switched to the case used in its original definition. This makes it
impossible to use the same word with a different case.

> PHP is the sole execption (CMIIW) – and the potential
>cognitive overhead during programming is hard to justify. Constants are
>the icing on the cake: they can be either case-insensitive or
>case-sensitive at the discression of the dev defining the constant.
>Using an extension which defines case-insensitive constants might raise
>the following issue:
>
> <?php
> define('FOO', true, true); // public const in ext; transcript from C
> const FOO = false; // in global app code
>
>Why doesn't that fail? How am I supposed to write the extension
>constant afterwards? Ah, yes, `foo`, of course! The PHP manual
>explains that quite clearly, so there must be a bug in my IDE and the
>docs of the extension. Oh, it's home time – I'm going to enjoy a nice
>evening reading Brainf*ck code… ;)
>
>FTR: there are 2811 occurances of REGISTER_\w+\_CONSTANT in current
>php-src master, all of which use CONST_CS. phpinternalsbook.com
>mentions succinctly:
>
>| The flags are mixed OR operation between CONST_CS (case-sensitive
>| constant, what we want), […]
>
>I completely fail to see why we should retain the possibility to define
>case-insensitive constants in extensions. Deprecate that for PHP 7.3.0
>(which is more than a year away) and remove in PHP 8.0.0 (which might be
>several years away) seems to be acceptable. IMHO we should strive to
>remove accidental complexity as soon as possible (and clearly, this is
>not essential complexity).

Although the PHP manual says that constants are case-insensitive, it also
says that by convention all constants are uppercase. I have been following
that convention, so a change to make constants case sensitive instead of
insensitive would not bother me. In fact it would not bother me if
user-defined constants could only ever be in upper case as that would remove
any possible confusion between 'foo' and 'Foo'.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login