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

This is only part of a thread. view whole thread
  100566
September 13, 2017 17:24 pollita@php.net (Sara Golemon)
On Wed, Sep 13, 2017 at 8:59 AM, Tony Marston <TonyMarston@hotmail.com> wrote:
> "Sara Golemon" wrote in message > news:CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=U_F3gd87rmxrQ@mail.gmail.com... >> +0.1 to removing case-insensitive constants, though we'd need to >> define both "null" and "NULL" (similar for true and false) since >> there's little consensus on which version of these constants get used >> from project to project. Also: While deprecating for 7.3 is fine, I'd >> favor waiting for 8.0 for full removal. >> >> As to François' suggestion to make the whole language case-sensitive? >> Yeesh, that feels like a much more aggressive movement. In the case >> of constants they very nearly are case-sensitive only since, as you >> point out, common practice is to not pass true for that third >> parameter, and to prefer `const` over `define` anyway. Identifiers >> are another matter since they're insensitive by default. >> >> In the case of classnames I could almost get on board since >> autoloading standards have pushed users naturally in the direction of >> respecting case sensitive as a coding standard. I don't feel as >> though that's true of functions or of projects where autoloaders >> aren't used (not a small number). > > > You seem to forget that autoloading is an option, not a requirement. > I don't forget any such thing. I noted it as a phenomenon which has
*pushed* users in a particular direction, but by no means have all users gone that way, as you note about yourself. Indeed, I have a 10 year old framework still in use at a previous company which does many similar things for many similar reasons. I also stated that I could *almost* get on board. Almost is not 100%, it's arguably not even 50% since it implies not actually crossing some minimum required threshold.
> - I don't like the way autoloaders work - all my class names are in snake > case (lowercase with underscore separators) and the autoloader converts '_' > into '/' thus producing a file path which does not exist. > Nit; That's autoloader specific. PSR-0 defines that behavior, but
PSR-4 does not, for example.
> By convention I always use uppercase for constants which makes them > instantly recognisable in my code as all other names are either completely > lowercase or mixed case. Making constants case sensitive instead of > insensitive would not affect me. > Agreed, nor I suspect would it effect most other users regardless of
which case they use since the trend is to not use case-insensitive constants in the first place.
> People who think that case sensitive software is cool are deluding > themselves. When I started working on mainframe computers (UNIVAC and IBM) > in the early 1970s everything was case-insensitive. This was only changed by > people who did not understand the ramifications of their choice. > Yeah, decades of C/C++/Java developers are so dumb, like... fer reals.
Friggin' script kiddies, the lot of 'em. -Sara
  100575
September 14, 2017 09:20 TonyMarston@hotmail.com ("Tony Marston")
"Sara Golemon"  wrote in message 
news:CAESVnVp6OKB64WuO9iKEP=L9-QrrFjS+kcoeKYKULRUff-RitQ@mail.gmail.com...
> >On Wed, Sep 13, 2017 at 8:59 AM, Tony Marston <TonyMarston@hotmail.com> >wrote:
>> People who think that case sensitive software is cool are deluding >> themselves. When I started working on mainframe computers (UNIVAC and >> IBM) >> in the early 1970s everything was case-insensitive. This was only changed >> by >> people who did not understand the ramifications of their choice. >> >Yeah, decades of C/C++/Java developers are so dumb, like... fer reals. >Friggin' script kiddies, the lot of 'em. > >-Sara
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. It is the same for file systems - all the pre-unix systems I worked on were case insensitive, as have been all versions of Microsoft Windows. Then unix came along and FUBAR'd everything. Any advantages of case sensitive systems are ALWAYS outweighed by their disadvantages. A similar cockup occurred with line endings. The original convention on teletypes was to use line-feed (LF) and carriage-return (CR) together which have separate meanings and could either be used independently or together. Then some clueless newbies came along and changed everything so that some OSes use just LF while others use just just CR. This now causes problems when transferring files from one OS to another. This shows what happens when "friggin' script kiddies" (your words, not mine) come up with an idea without understanding what the current convention is. -- Tony Marston
  100577
September 14, 2017 09:40 daniel@honestempire.com (Daniel Morris)
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 daniel@honestempire.com
  100581
September 14, 2017 12:59 TonyMarston@hotmail.com ("Tony Marston")
"Daniel Morris"  wrote in message 
news:1505382004.4078127.1105791680.3A06C2FA@webmail.messagingengine.com...
> >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 >daniel@honestempire.com
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
  100585
September 14, 2017 13:27 cmbecker69@gmx.de ("Christoph M. Becker")
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
  100588
September 14, 2017 13:36 TonyMarston@hotmail.com ("Tony Marston")
""Christoph M. Becker""  wrote in message 
news:98ab178e-b999-7e36-5ff5-7b8c28fe0dd4@gmx.de...
> >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
  100590
September 14, 2017 13:46 addw@phcomp.co.uk (Alain Williams)
On Thu, Sep 14, 2017 at 02:36:27PM +0100, Tony Marston wrote:
> ""Christoph M. Becker"" wrote in message > news:98ab178e-b999-7e36-5ff5-7b8c28fe0dd4@gmx.de... > > > >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
  100610
September 15, 2017 09:02 TonyMarston@hotmail.com ("Tony Marston")
"Alain Williams"  wrote in message 
news:20170914134603.GS8096@phcomp.co.uk...
> >On Thu, Sep 14, 2017 at 02:36:27PM +0100, Tony Marston wrote: >> ""Christoph M. Becker"" wrote in message >> news:98ab178e-b999-7e36-5ff5-7b8c28fe0dd4@gmx.de... >> > >> >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
  100623
September 15, 2017 12:44 lester@lsces.co.uk (Lester Caine)
On 15/09/17 10:02, Tony Marston wrote:
> Why is it not possible to identify a single upper and lower case variant > for every character in every character set?
Can't find the right unicode standard page, but https://www.elastic.co/guide/en/elasticsearch/guide/current/case-folding.html sums it up. -- 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
  100631
September 15, 2017 14:54 TonyMarston@hotmail.com ("Tony Marston")
"Lester Caine"  wrote in message 
news:55603872-e832-65ea-25b6-48e01074a4c7@lsces.co.uk...
> >On 15/09/17 10:02, Tony Marston wrote: >> Why is it not possible to identify a single upper and lower case variant >> for every character in every character set? > >Can't find the right unicode standard page, but >https://www.elastic.co/guide/en/elasticsearch/guide/current/case-folding.html >sums it up. >
Try this page: http://unicode.org/faq/casemap_charprop.html Notice that case folding for case insensitive comparisons is relatively easy when compared with case switching. -- Tony Marston
  100586
September 14, 2017 13:27 rowan.collins@gmail.com (Rowan Collins)
On 14 September 2017 13:59:20 BST, Tony Marston <TonyMarston@hotmail.com> 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]
  100591
September 14, 2017 13:48 TonyMarston@hotmail.com ("Tony Marston")
"Rowan Collins"  wrote in message 
news:7394E3CE-B05A-474E-8AB5-A651FDD35232@gmail.com...
> >On 14 September 2017 13:59:20 BST, Tony Marston <TonyMarston@hotmail.com> >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
  100593
September 14, 2017 13:55 addw@phcomp.co.uk (Alain Williams)
On Thu, Sep 14, 2017 at 02:48:06PM +0100, Tony Marston wrote:
> "Rowan Collins" wrote in message > news:7394E3CE-B05A-474E-8AB5-A651FDD35232@gmail.com... > > > >On 14 September 2017 13:59:20 BST, Tony Marston > ><TonyMarston@hotmail.com> 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
  100611
September 15, 2017 09:04 TonyMarston@hotmail.com ("Tony Marston")
"Alain Williams"  wrote in message 
news:20170914135519.GW8096@phcomp.co.uk...
> >On Thu, Sep 14, 2017 at 02:48:06PM +0100, Tony Marston wrote: >> "Rowan Collins" wrote in message >> news:7394E3CE-B05A-474E-8AB5-A651FDD35232@gmail.com... >> > >> >On 14 September 2017 13:59:20 BST, Tony Marston >> ><TonyMarston@hotmail.com> 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
  100594
September 14, 2017 14:05 daniel@honestempire.com (Daniel Morris)
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
  100612
September 15, 2017 09:12 TonyMarston@hotmail.com ("Tony Marston")
"Daniel Morris"  wrote in message 
news:1505397937.4137791.1106049000.16B8878B@webmail.messagingengine.com...
> >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
  100614
September 15, 2017 09:21 addw@phcomp.co.uk (Alain Williams)
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
  100625
September 15, 2017 14:15 TonyMarston@hotmail.com ("Tony Marston")
"Alain Williams"  wrote in message 
news:20170915092114.GH8096@phcomp.co.uk...
> >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.
You are missing the point. The convention in the whole of the English-speaking world is exactly the same - it has both upper and lower case characters, and the meaning of a word does not change simply because some characters are written in a different case. When a person searches for a word in a dictionary he is not bothered about case. When a person searches for a file in the Windows OS he is not bothered about case. When a person searches for a word inside a file he is not bothered about case. I has seen some search mechanisms which provide the option to make the search case sensitive, but that is an option which has to be turned on - the default is still case insensitive. Can you show me any dictionary in ANY language where the same word has different meanings just by changing the case of one or more characters? Can you show me any language where a single character has multiple alternatives when switching case? By my reckoning case insensitivity has been the default way before computers were invented, and all the software on the early computers was also case insensitive. I have worked on numerous hardware platforms since the 1970s, and they were ALL case insensitive. -- Tony Marston
  100627
September 15, 2017 14:27 lists@rhsoft.net ("lists@rhsoft.net")
Am 15.09.2017 um 16:15 schrieb Tony Marston:
> Can you show me any language where a single character has multiple > alternatives when switching case?
http://cdn.webfail.com/upl/img/07181c2ca27/post2.jpg _____________________________________ german: Sie ist wirklich gut zu Vögeln english: she is really nice to birds german: Sie ist wirkich gut zu vögeln english: she is really nice to fuck _____________________________________ german: Ich wünschte er wäre Dichter! english: i wish he would be a poet german: Ich ünschte er wäre dichter! english: i wish he would be more drunken _____________________________________ and now stop it!
  100659
September 16, 2017 09:16 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:c257f203-2c8e-f6d3-f5cd-597310957755@rhsoft.net...
> > > >Am 15.09.2017 um 16:15 schrieb Tony Marston: >> Can you show me any language where a single character has multiple >> alternatives when switching case? > >http://cdn.webfail.com/upl/img/07181c2ca27/post2.jpg >_____________________________________ > >german: Sie ist wirklich gut zu Vögeln >english: she is really nice to birds > >german: Sie ist wirkich gut zu vögeln >english: she is really nice to fuck >_____________________________________ > >german: Ich wünschte er wäre Dichter! >english: i wish he would be a poet > >german: Ich ünschte er wäre dichter! >english: i wish he would be more drunken >_____________________________________ > >and now stop it!
Even in the English language there are words which which can have different meanings depending on the context, but there are NO circumstances where a word means one thing when it is in lowercase and something else when it is in uppercase. The rules change when several words are grouped together in a sentence. For example, the sentence "He is pissed" can have two possible meanings: pissed - meaning "drunk" pissed - meaning "pissed off" or "unhappy" There is no such thing as "Pissed with a capital 'P' means drunk" and "pissed with a lowercase 'p' means unhappy". The idea that the entire universe should have to change its rules regarding switching between upper and lowercase just to satisfy a few anomalies concocted by the master race is laughable. -- Tony Marston
  100670
September 16, 2017 09:54 cmbecker69@gmx.de ("Christoph M. Becker")
On 16.09.2017 at 11:16, Tony Marston wrote:

> There is no such thing as "Pissed with a capital 'P' means drunk" and > "pissed with a lowercase 'p' means unhappy".
"It's Nice" vs. "It's nice".
> The idea that the entire universe should have to change its rules > regarding switching between upper and lowercase just to satisfy a few > anomalies concocted by the master race is laughable.
Godwin's law fulfilled, again. Sad. -- Christoph M. Becker
  100673
September 16, 2017 10:56 TonyMarston@hotmail.com ("Tony Marston")
""Christoph M. Becker""  wrote in message 
news:7f14af9e-cd8c-3a73-e487-7219a7630f99@gmx.de...
> >On 16.09.2017 at 11:16, Tony Marston wrote: > >> There is no such thing as "Pissed with a capital 'P' means drunk" and >> "pissed with a lowercase 'p' means unhappy". > >"It's Nice" vs. "It's nice".
"Nice" pronounced "nyce" means the same thing regardless of case. "Nice" pronounced "neece" is a place name, so "I went to Nice" means the same thing as "I WENT TO NICE". You could even write it as "i went to nice" and people would understand what you meant.
>> The idea that the entire universe should have to change its rules >> regarding switching between upper and lowercase just to satisfy a few >> anomalies concocted by the master race is laughable. > >Godwin's law fulfilled, again. Sad.
Excuse me, but I have not mentioned anywhere that Austrian corporal or his political persuasions, so this law has not been fulfilled. Unless you are telling me that all German people are cast from the same mould. -- Tony Marston
  100694
September 18, 2017 04:38 spam-free@blueyonder.co.uk (niel)
On 16/09/17 11:56, Tony Marston wrote:
> ""Christoph M. Becker"" wrote in message > news:7f14af9e-cd8c-3a73-e487-7219a7630f99@gmx.de... >> >> On 16.09.2017 at 11:16, Tony Marston wrote: >> >>> There is no such thing as "Pissed with a capital 'P' means drunk" and >>> "pissed with a lowercase 'p' means unhappy". >> >> "It's Nice" vs. "It's nice". > > "Nice" pronounced "nyce" means the same thing regardless of case. "Nice" > pronounced "neece" is a place name, so "I went to Nice" means the same > thing as "I WENT TO NICE". You could even write it as "i went to nice" > and people would understand what you meant. > >>> The idea that the entire universe should have to change its rules >>> regarding switching between upper and lowercase just to satisfy a few >>> anomalies concocted by the master race is laughable. >> >> Godwin's law fulfilled, again. Sad. > > Excuse me, but I have not mentioned anywhere that Austrian corporal or > his political persuasions, so this law has not been fulfilled. Unless > you are telling me that all German people are cast from the same mould. > Try China vs. china
One is a country, the other is a type of ceramic.
  100695
September 18, 2017 09:40 TonyMarston@hotmail.com ("Tony Marston")
"niel"  wrote in message 
news:f75fe28a-9002-401c-f863-4462251e2e7b@blueyonder.co.uk...
> >On 16/09/17 11:56, Tony Marston wrote: >> ""Christoph M. Becker"" wrote in message >> news:7f14af9e-cd8c-3a73-e487-7219a7630f99@gmx.de... >>> >>> On 16.09.2017 at 11:16, Tony Marston wrote: >>> >>>> There is no such thing as "Pissed with a capital 'P' means drunk" and >>>> "pissed with a lowercase 'p' means unhappy". >>> >>> "It's Nice" vs. "It's nice". >> >> "Nice" pronounced "nyce" means the same thing regardless of case. "Nice" >> pronounced "neece" is a place name, so "I went to Nice" means the same >> thing as "I WENT TO NICE". You could even write it as "i went to nice" >> and people would understand what you meant. >> >>>> The idea that the entire universe should have to change its rules >>>> regarding switching between upper and lowercase just to satisfy a few >>>> anomalies concocted by the master race is laughable. >>> >>> Godwin's law fulfilled, again. Sad. >> >> Excuse me, but I have not mentioned anywhere that Austrian corporal or >> his political persuasions, so this law has not been fulfilled. Unless you >> are telling me that all German people are cast from the same mould. >> >Try China vs. china >One is a country, the other is a type of ceramic.
I have already acknowledged that the same word can have a different meaning in a different context, so the word "china" has a different meaning in "I am going to China" and "this is made from china". However, in the same context changes in case are irrelevant: "I AM GOING TO CHINA" is the same as "i am going to china". "THIS IS MADE FROM CHINA" is the same as "this is made from china". -- Tony Marston
  100696
September 18, 2017 10:40 cmbecker69@gmx.de ("Christoph M. Becker")
On 18.09.2017 at 11:40, Tony Marston wrote:

> I have already acknowledged that the same word can have a different > meaning in a different context, so the word "china" has a different > meaning in "I am going to China" and "this is made from china". However, > in the same context changes in case are irrelevant: > > "I AM GOING TO CHINA" is the same as "i am going to china". > "THIS IS MADE FROM CHINA" is the same as "this is made from china".
The same written (and this is what we're talking about; pronunciation is irrelevant here) English word can have different meaning in the same context, too. One may say "This is nice!" (to show appreciation) and "This is Nice!" (to refer to the city). Also many professions which are also common names have the same issue ("This is the miller" vs. "This is the Miller"). You may recognize the common pattern, namely that proper names are capitalized in English. In German, and likely some other languages as well, all nouns are capitalized, so there are obviously many more such cases. However, that does not necessarily mean that I prefer case-sensivity over case-insensivity, but it would indeed greatly simplify the implementation, since case-folding is a rather complex issue. For instance, the German lower-case letter "ß" is traditionally written as "SS" in upper-case. So if I would define('STRASSE', $value, true), I might expect to be able to write "Straße". That wouldn't apply to "KRESSE", though, which has to be written as "Kresse". See also <https://www.w3.org/International/wiki/Case_folding>. -- Christoph M. Becker
  100704
September 19, 2017 09:24 TonyMarston@hotmail.com ("Tony Marston")
""Christoph M. Becker""  wrote in message 
news:e8590cd8-8e85-9f2f-470f-f612b2b0fee8@gmx.de...
> >On 18.09.2017 at 11:40, Tony Marston wrote: > >> I have already acknowledged that the same word can have a different >> meaning in a different context, so the word "china" has a different >> meaning in "I am going to China" and "this is made from china". However, >> in the same context changes in case are irrelevant: >> >> "I AM GOING TO CHINA" is the same as "i am going to china". >> "THIS IS MADE FROM CHINA" is the same as "this is made from china". > >The same written (and this is what we're talking about; pronunciation is >irrelevant here) English word can have different meaning in the same >context, too. One may say "This is nice!" (to show appreciation) and >"This is Nice!" (to refer to the city). Also many professions which are >also common names have the same issue ("This is the miller" vs. "This is >the Miller"). You may recognize the common pattern, namely that proper >names are capitalized in English. In German, and likely some other >languages as well, all nouns are capitalized, so there are obviously >many more such cases.
You are talking about slight differences in human-to-human communication which is totally irrelevant. This topic is about switching case in software, and in such cases those differences are irrelevant. If my software switches case so that "this is nice" becomes "THIS IS NICE" or vice versa, then it does not matter one jot that "nice" could mean a place, or something pleasant, or even the initials of The National Institute for Health and Care Excellence. Inside the computer it does not matter. The fact that "title case" means different things in different languages is irrelevant. If it is implemented in the standard (i.e English) way then it does not make the sentence unreadable in those foreign languages, so those foreign johnnys should learn to live with it.
>However, that does not necessarily mean that I prefer case-sensivity >over case-insensivity, but it would indeed greatly simplify the >implementation, since case-folding is a rather complex issue.
I have always been taught that there are only two ways of doing a job - either "properly" or "not at all". The exceptions in switching between upper and lowercase should be built into the Unicode engine then the problem is solved properly. Removing case insensitivity completely is not a proper solution as it removes a feature that we humans have been used to for decades. This would be a case where the cure is even worse than the disease.
> For >instance, the German lower-case letter "ß" is traditionally written as >"SS" in upper-case. So if I would define('STRASSE', $value, true), I >might expect to be a ble to write "Straße". That wouldn't apply to >"KRESSE", though, which has to be written as "Kresse". See also ><https://www.w3.org/International/wiki/Case_folding>.
If the single character "ß" represents two "s" characters joined together, then the uppercase equivalent should also be a single character which looks like two "S" characters joined together. If it is not possible to write code which deals with these exceptions, then one alternative would be to remove these exceptions. -- Tony Marston
  100705
September 19, 2017 09:35 lists@rhsoft.net ("lists@rhsoft.net")
Am 19.09.2017 um 11:24 schrieb Tony Marston:
> If the single character  "ß" represents two "s" characters joined > together, then the uppercase equivalent should also be a single > character which looks like two "S" characters joined together. If it is > not possible to write code which deals with these exceptions, then one > alternative would be to remove these exceptions
remove from where? from the reality? have fun, it becomes even more complexer and currently it's in discussion where to place the uppercase on a keyboard https://en.wikipedia.org/wiki/%C3%9F#Capital_form > If the single character "ß" represents two "s" no, until short ago there where just no uppercase one and that's only about german - you still missed *to prove* "Removing case insensitivity completely is not a proper solution as it removes a feature that we humans have been used to for decades" since i know nobody right in his mind which writes inconsistent code where this is a real world problem and if someone writtes "my_function", "MY_function" and "my_Function" in his code and don#t stop that nosnese he simply get fired
  100709
September 20, 2017 09:30 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:098adca8-6897-929d-90e4-cc464f0e22a2@rhsoft.net...
> > > >Am 19.09.2017 um 11:24 schrieb Tony Marston: >> If the single character "ß" represents two "s" characters joined >> together, then the uppercase equivalent should also be a single character >> which looks like two "S" characters joined together. If it is not >> possible to write code which deals with these exceptions, then one >> alternative would be to remove these exceptions > >remove from where? >from the reality?
If the lowercase character "ß" causes so many problems because it has no proper equivalent in uppercase then it should be removed from the list of valid characters. Either that or provide a single uppercase character - which is what that wikipedia article you quoted says actually happened this year.
>have fun, it becomes even more complexer and currently it's in discussion >where to place the uppercase on a keyboard >https://en.wikipedia.org/wiki/%C3%9F#Capital_form > > > If the single character "ß" represents two "s" > >no, until short ago there where just no uppercase one and that's only about >german - you still missed *to prove* "Removing case insensitivity >completely is not a proper solution as it removes a feature that we humans >have been used to for decades"
When we search for a word in a dictionary we do not need to specify case as that is irrelevant, so "sausage" is the same as "SAUSAGE". There are words which can have different meanings depending on the context, such as "this cup is made of china" and "I am going to China", but provided that the context remains the same then case is irrelevant. When it comes to software case insensitivity has been the standard since day 1. When searching for a file in MS Windows you do not have to specify case as it is not possible to have different files with the same name but different mixtures of case. When searching for a word or phrase in a text editor it is not necessary to specify case, although some editors include an option to make the search case sensitive.
>since i know nobody right in his mind which writes inconsistent code where >this is a real world problem and if someone writtes "my_function", >"MY_function" and "my_Function" in his code and don#t stop that nosnese he >simply get fired
That may be uncool, but the only problem it causes is in the tiny minds of OCD sufferers. By making the language case sensitive and allowing "my_function", "MY_function" and "my_Function" to be defined as separate functions with separate implementations would be inviting total disaster. -- Tony Marston
  100712
September 20, 2017 10:07 lester@lsces.co.uk (Lester Caine)
On 20/09/17 10:30, Tony Marston wrote:
> When it comes to software case insensitivity has been the standard since > day 1. When searching for a file in MS Windows you do not have to > specify case as it is not possible to have different files with the same > name but different mixtures of case.
When M$ screwed up the filing system by allowing spaces in file names and also dropping case sensitivity - to make life easier for none programmers - we had to get use to this 'new way of working'. It STILL causes problems today so no it was NOT standard from day 1. Although I can't remember now if DOS 8.3 file names enforced uppercase only but all other OS's at that time preserved case in file names. https://en.wikipedia.org/wiki/8.3_filename explains how VFAT added longer file names to FAT ... using an upper case file name below. File capabilities on https://en.wikipedia.org/wiki/Comparison_of_file_systems will demonstrate just how few file systems are case-insensitive. You will see that NTFS is ACTUALLY case-sensitive and it is only the WIN32 subsystem which prevents file names clashes. It's also that system which changes the case of a name when it's displayed or passed over to other systems :( That all said ... the rather limited question here is if the current very restricted case-insensitivity should be removed, or should it be expanded to properly handle constant names in other character sets? That then needs a LOT of work in other areas where the limited ascii case-insensitivity is allowed? Do we NEED case-insensitivity if that is one thing preventing a switch to use of unicode names in the code? -- 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
  100713
September 20, 2017 10:07 lists@rhsoft.net ("lists@rhsoft.net")
Am 20.09.2017 um 11:30 schrieb Tony Marston:
> wrote in message news:098adca8-6897-929d-90e4-cc464f0e22a2@rhsoft.net... >> >> >> >> Am 19.09.2017 um 11:24 schrieb Tony Marston: >>> If the single character  "ß" represents two "s" characters joined >>> together, then the uppercase equivalent should also be a single >>> character which looks like two "S" characters joined together. If it >>> is not possible to write code which deals with these exceptions, then >>> one alternative would be to remove these exceptions >> >> remove from where? >> from the reality? > > If the lowercase character "ß" causes so many problems because it has no > proper equivalent in uppercase then it should be removed from the list > of valid characters. Either that or provide a single uppercase character > - which is what that wikipedia article you quoted says actually happened > this year
jesus christ the german language DID NOT have a uppercase ß in the real world until recently but had the lowercase ß virtually forever how do you imagine "removeed from the list of valid characters" in that case - frankly that paragraph above shows clearly that you should stop to argue about this topic at all
  100714
September 20, 2017 10:49 jamesbwebdev@gmail.com (Jay B)
> > That may be uncool, but the only problem it causes is in the tiny minds of > OCD sufferers. >
Once again, you are being derogatory and continue to label others, who do not share your opinion, with a mental health condition. As you have been told previously (thread - https://externals. io/message/99241#99241); What you seem not to recognise is that any person has the right to
> suggest or campaign for such a change, regardless of their age, experience > level, pay grade, nerdiness or severity of OCD. To imply otherwise is > offensive. >
It's a shame that you're unable to have a discussion, on a public mailing list, without being rude, offensive and derogatory. It'd be better if you could stay on topic rather than sharing your thoughts on the mental health of others. On Wed, Sep 20, 2017 at 10:30 AM, Tony Marston <TonyMarston@hotmail.com> wrote:
> wrote in message news:098adca8-6897-929d-90e4-cc464f0e22a2@rhsoft.net... > >> >> >> >> Am 19.09.2017 um 11:24 schrieb Tony Marston: >> >>> If the single character "ß" represents two "s" characters joined >>> together, then the uppercase equivalent should also be a single character >>> which looks like two "S" characters joined together. If it is not possible >>> to write code which deals with these exceptions, then one alternative would >>> be to remove these exceptions >>> >> >> remove from where? >> from the reality? >> > > If the lowercase character "ß" causes so many problems because it has no > proper equivalent in uppercase then it should be removed from the list of > valid characters. Either that or provide a single uppercase character - > which is what that wikipedia article you quoted says actually happened this > year. > > have fun, it becomes even more complexer and currently it's in discussion >> where to place the uppercase on a keyboard >> https://en.wikipedia.org/wiki/%C3%9F#Capital_form >> >> > If the single character "ß" represents two "s" >> >> no, until short ago there where just no uppercase one and that's only >> about german - you still missed *to prove* "Removing case insensitivity >> completely is not a proper solution as it removes a feature that we humans >> have been used to for decades" >> > > When we search for a word in a dictionary we do not need to specify case > as that is irrelevant, so "sausage" is the same as "SAUSAGE". There are > words which can have different meanings depending on the context, such as > "this cup is made of china" and "I am going to China", but provided that > the context remains the same then case is irrelevant. > > When it comes to software case insensitivity has been the standard since > day 1. When searching for a file in MS Windows you do not have to specify > case as it is not possible to have different files with the same name but > different mixtures of case. > > When searching for a word or phrase in a text editor it is not necessary > to specify case, although some editors include an option to make the search > case sensitive. > > since i know nobody right in his mind which writes inconsistent code where >> this is a real world problem and if someone writtes "my_function", >> "MY_function" and "my_Function" in his code and don#t stop that nosnese he >> simply get fired >> > > That may be uncool, but the only problem it causes is in the tiny minds of > OCD sufferers. By making the language case sensitive and allowing > "my_function", "MY_function" and "my_Function" to be defined as separate > functions with separate implementations would be inviting total disaster. > > -- > Tony Marston > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  100618
September 15, 2017 09:53 lists@rhsoft.net ("lists@rhsoft.net")
Am 15.09.2017 um 11:12 schrieb Tony Marston:
> 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
and a competent programmer using PHP as programming language would not define a funtion do_something() and write "Do_Something", "do_Something", "DO_something" all over his codebase the problem which makes such a change dramatic is the poor code quality of most projects and as i remeber you even fighted some months ago that a consistent coding style within a project is nothing you care about and that explains how you argue here very well -------- Weitergeleitete Nachricht -------- Betreff: Re: [PHP-DEV] Class Naming in Core Datum: Mon, 5 Jun 2017 09:14:47 +0100 Von: Tony Marston <TonyMarston@hotmail.com> An: internals@lists.php.net Seriously, can you explain in words of one syllable the precise benefits of such a consistency? Can you measure the benefits? Just because some OCD sufferers like consistency is not a good enough reason. I have been programming for over 30 years, and in that time I have had to deal with both snake_case and CamelCase, and while I personally find that snake_case is more readable, especially with names that contain more than 3 or 4 words, I have no trouble reading either. Having a mixture of styles does not cause a problem (except in the minds of OCD sufferers) so IMHO it does not require a solution. Anybody who says that they cannot work with a mixture of naming styles is either a liar or Illiterate.
  100628
September 15, 2017 14:38 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:8bbcc1fc-0d13-27d4-a04f-0a5ebda4c32e@rhsoft.net...
> >Am 15.09.2017 um 11:12 schrieb Tony Marston: >> 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 > >and a competent programmer using PHP as programming language would not >define a funtion do_something() and write "Do_Something", "do_Something", >"DO_something" all over his codebase
While that may be "uncool" or even "inconsistent" it does not cause a genuine problem. But you seem to be supporting a change which would be worse than uncool, it would be downright horrific. No human language that I know of allows a word to change its meaning just by changing the case of one or more characters, and this standard behaviour was echoed in all the computer systems that I have used since the 1970s. The fact that I can create a function called do_something() and later refer to it as either Do_something(), do_Something() or even Do_SomeThing() may be annoying but it is irrelevant. Do you realise how many problems it would cause if each change in case pointed to a totally different function? Would you support anyone who proposed adding a series of functions to PHP core or an extension where every function used exactly the same words but in a different case? What will happen in the future if we move away from keyboard input towards speech input? It will not be good enough to simply say a word, you would have to spell it out character by character and specify the case of each character. Do you think that would be a good idea?
>the problem which makes such a change dramatic is the poor code quality of >most projects and as i remeber you even fighted some months ago that a >consistent coding style within a project is nothing you care about and that >explains how you argue here very well
I'm afraid that changing the way I do things just to be "consistent" with others is not a good argument when it ends up being "consistently bad".
>-------- Weitergeleitete Nachricht -------- >Betreff: Re: [PHP-DEV] Class Naming in Core >Datum: Mon, 5 Jun 2017 09:14:47 +0100 >Von: Tony Marston <TonyMarston@hotmail.com> >An: internals@lists.php.net > >Seriously, can you explain in words of one syllable the precise benefits of >such a consistency? Can you measure the benefits? Just because some OCD >sufferers like consistency is not a good enough reason. I have been >programming for over 30 years, and in that time I have had to deal with >both snake_case and CamelCase, and while I personally find that snake_case >is more readable, especially with names that contain more than 3 or 4 >words, I have no trouble reading either. Having a mixture of styles does >not cause a problem (except in the minds of OCD sufferers) so IMHO it does >not require a solution. Anybody who says that they cannot work with a >mixture of naming styles is either a liar or Illiterate.
-- Tony Marston
  100629
September 15, 2017 14:48 lists@rhsoft.net ("lists@rhsoft.net")
Am 15.09.2017 um 16:38 schrieb Tony Marston:
> wrote in message news:8bbcc1fc-0d13-27d4-a04f-0a5ebda4c32e@rhsoft.net... >> >> Am 15.09.2017 um 11:12 schrieb Tony Marston: >>> 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 >> >> and a competent programmer using PHP as programming language would not >> define a funtion do_something() and write "Do_Something", >> "do_Something", "DO_something" all over his codebase > > While that may be "uncool" or even "inconsistent" it does not cause a > genuine problem. But you seem to be supporting a change which would be > worse than uncool, it would be downright horrific. No human language > that I know of allows a word to change its meaning just by changing the > case of one or more characters
i brought you samples of german where the meanining of the same word changes *dramatically* - "nett zu Vögeln" versus "nett zu vögeln" which goes from "nice to birds" to "nice to fuck"
> and this standard behaviour was echoed > in all the computer systems that I have used since the 1970s. The fact > that I can create a function called do_something() and later refer to it > as either Do_something(), do_Something() or even Do_SomeThing() may be > annoying but it is irrelevant. Do you realise how many problems it would > cause if each change in case pointed to a totally different function?
only when one is so short-sighted as you act it's not rocket science at compile time throw a error that you are not allowed to define foo() and Foo() in the same software which has no runtime costs and after that you may even have less runtime costs because all the case-insensitive handling can be skipped and well, for the time of deprecation the compiler code with finally throws errors can issue the warnings with file and line - i assure you that going to fix that warnings takes less time than the whole discussion with you over the last days from several people
> Would you support anyone who proposed adding a series of functions to > PHP core or an extension where every function used exactly the same > words but in a different case? see above - just because you assume it's rocket scienece doesn't mean it is
  100660
September 16, 2017 09:29 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:ba7ed73b-8547-2029-7344-6705a70c6015@rhsoft.net...
> > > >Am 15.09.2017 um 16:38 schrieb Tony Marston: >> wrote in message news:8bbcc1fc-0d13-27d4-a04f-0a5ebda4c32e@rhsoft.net... >>> >>> Am 15.09.2017 um 11:12 schrieb Tony Marston: >>>> 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 >>> >>> and a competent programmer using PHP as programming language would not >>> define a funtion do_something() and write "Do_Something", >>> "do_Something", "DO_something" all over his codebase >> >> While that may be "uncool" or even "inconsistent" it does not cause a >> genuine problem. But you seem to be supporting a change which would be >> worse than uncool, it would be downright horrific. No human language that >> I know of allows a word to change its meaning just by changing the case >> of one or more characters > >i brought you samples of german where the meanining of the same word >changes *dramatically* - "nett zu Vögeln" versus "nett zu vögeln" which >goes from "nice to birds" to "nice to fuck" > >> and this standard behaviour was echoed in all the computer systems that I >> have used since the 1970s. The fact that I can create a function called >> do_something() and later refer to it as either Do_something(), >> do_Something() or even Do_SomeThing() may be annoying but it is >> irrelevant. Do you realise how many problems it would cause if each >> change in case pointed to a totally different function? > >only when one is so short-sighted as you act > >it's not rocket science at compile time throw a error that you are not >allowed to define foo() and Foo() in the same software which has no runtime >costs and after that you may even have less runtime costs because all the >case-insensitive handling can be skipped
None of the IDEs that I have used have enforced such a rule, neither have any languages, so it is an artificial rule invented by someone who doesn't now how to provide a proper solution. As I have said in several other posts, the vast majority of the human race has come to accept case-insensitive software, and if you can't implement it then you should step aside and make room for someone who can.
>and well, for the time of deprecation the compiler code with finally throws >errors can issue the warnings with file and line - i assure you that going >to fix that warnings takes less time than the whole discussion with you >over the last days from several people > >> Would you support anyone who proposed adding a series of functions to PHP >> core or an extension where every function used exactly the same words but >> in a different case?
>see above - just because you assume it's rocket scienece doesn't mean it is
You seem to misunderstand the term "rocket science" which means that something is so difficult that it can only be done by a highly trained individual. Something which is NOT rocket science is supposed to be so easy that anyone can do, not just a scientist. People keep telling me that switching between upper and lower case for all character sets in the universe is not 100% simple because of a small number of exceptions. So what? Identify the exceptions and write code which deals with them. If we only wrote deal to deal with the easy stuff there would be no need for highly skilled programmers as anyone could do it. -- Tony Marston
  100664
September 16, 2017 09:40 addw@phcomp.co.uk (Alain Williams)
On Sat, Sep 16, 2017 at 10:29:26AM +0100, Tony Marston wrote:

> People keep telling me that switching between upper and lower case > for all character sets in the universe is not 100% simple because of > a small number of exceptions. So what? Identify the exceptions and > write code which deals with them.
Thereby increasing the complexity of the PHP engine - which means more bugs and slower execution. It also makes it harder for the user to understand: they need to get their heads round the corner cases. -- 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
  100672
September 16, 2017 10:50 TonyMarston@hotmail.com ("Tony Marston")
"Alain Williams"  wrote in message 
news:20170916094055.GM8096@phcomp.co.uk...
> >On Sat, Sep 16, 2017 at 10:29:26AM +0100, Tony Marston wrote: > >> People keep telling me that switching between upper and lower case >> for all character sets in the universe is not 100% simple because of >> a small number of exceptions. So what? Identify the exceptions and >> write code which deals with them. > >Thereby increasing the complexity of the PHP engine - which means more bugs >and >slower execution. It also makes it harder for the user to understand: they >need >to get their heads round the corner cases.
There should be no need to complicate the entire PHP engine. Just fix the UNICODE exceptions so that strtoupper() and strtolower() work properly for that small number of peculiar character sets. -- Tony Marston
  100580
September 14, 2017 12:33 lester@lsces.co.uk (Lester Caine)
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
  100582
September 14, 2017 13:10 tendoaki@gmail.com (Michael Morris)
On Thu, Sep 14, 2017 at 8:33 AM, Lester Caine <lester@lsces.co.uk> 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.
  100587
September 14, 2017 13:32 lester@lsces.co.uk (Lester Caine)
On 14/09/17 14:10, Michael Morris wrote:
> On Thu, Sep 14, 2017 at 8:33 AM, Lester Caine <lester@lsces.co.uk> 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
  100583
September 14, 2017 13:16 TonyMarston@hotmail.com ("Tony Marston")
"Lester Caine"  wrote in message 
news:20b8b6fa-ec81-eba9-d33b-b54b815e9e5d@lsces.co.uk...
> >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
  100589
September 14, 2017 13:38 addw@phcomp.co.uk (Alain Williams)
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
  100595
September 14, 2017 15:37 francois@tekwire.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)
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
  100597
September 14, 2017 15:45 pollita@php.net (Sara Golemon)
On Thu, Sep 14, 2017 at 11:37 AM, François Laupretre
<francois@tekwire.net> 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
  100600
September 14, 2017 16:25 cmbecker69@gmx.de ("Christoph M. Becker")
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
  100609
September 15, 2017 08:51 TonyMarston@hotmail.com ("Tony Marston")
"Alain Williams"  wrote in message 
news:20170914133846.GQ8096@phcomp.co.uk...
> >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
  100613
September 15, 2017 09:17 narf@devilix.net (Andrey Andreev)
Hi,

On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston <TonyMarston@hotmail.com> 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.
  100617
September 15, 2017 09:46 TonyMarston@hotmail.com ("Tony Marston")
"Andrey Andreev"  wrote in message 
news:CAPhkiZyXgxi-7vWdqA2hxni9SvycuN_pWOOM8un8mUo5qJ=0jg@mail.gmail.com...
> >Hi, > >On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston <TonyMarston@hotmail.com> >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?
How many people in the world work with PCs running Microsoft Windows? More than those running alternatives.
>And how many of them have ever encountered case-sensitivity as a concept?
None, because they have always used case-insensitive software.
>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?
When searching for a file in Windows it is not necessary to now what case it was created in. When searching for a word in a file it is not necessary to now what case it was created in. TRy taking that ability away from Windows users and see what reaction you get.
>Also, are we Microsoft developers? Are we trying to change Windows?
No, but you are suggesting a change from being consistent with Windows to being inconsistent.
>And most importantly: How do everyday Windows users have anything to >do with PHP developers?
Some people are also Windows users as well as PHP developers, and if those people are told that some of the software which they use is now being switched from being case-insensitive to case-sensitive just because the programmers cannot solve a small problem which only affects a small number of character sets, then those people will not be happy. Case-insensitive software has been around for decades and is regarded by many users as a feature. It that "feature" is broken in a small number of cases then a proper programmer would fix that broken feature and not advocate for its removal just because it is more convenient than developing a fix. -- Tony Marston
  100620
September 15, 2017 10:08 narf@devilix.net (Andrey Andreev)
Hi again,

On Fri, Sep 15, 2017 at 12:46 PM, Tony Marston <TonyMarston@hotmail.com> wrote:
> "Andrey Andreev" wrote in message > news:CAPhkiZyXgxi-7vWdqA2hxni9SvycuN_pWOOM8un8mUo5qJ=0jg@mail.gmail.com... >> >> >> Hi, >> >> On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston <TonyMarston@hotmail.com> >> 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? > > > How many people in the world work with PCs running Microsoft Windows? More > than those running alternatives. >
So you admit that you just made up the number?
>> And how many of them have ever encountered case-sensitivity as a concept? > > > None, because they have always used case-insensitive software. >
And that will not change, regardless of how PHP constants work. Thus, re-inforcing my point - that you're completely off-topic.
>> 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? > > > When searching for a file in Windows it is not necessary to now what case it > was created in. When searching for a word in a file it is not necessary to > now what case it was created in. TRy taking that ability away from Windows > users and see what reaction you get. >
1. Search is a feature that goes way beyond case-sensitivity, and that was not what I was (rhetorically) asking. 2. Unless Windows users search for filenames matching constants declared in PHP code, this is irrelevant.
>> Also, are we Microsoft developers? Are we trying to change Windows? > > > No, but you are suggesting a change from being consistent with Windows to > being inconsistent. >
It *happens* to be consistent; nobody has ever cared about whether it is or not. And I am not suggesting anything. I am simply pointing out the ridiculous false-equivalences you're making.
>> And most importantly: How do everyday Windows users have anything to >> do with PHP developers? > > > Some people are also Windows users as well as PHP developers, and if those > people are told that some of the software which they use is now being > switched from being case-insensitive to case-sensitive just because the > programmers cannot solve a small problem which only affects a small number > of character sets, then those people will not be happy. Case-insensitive > software has been around for decades and is regarded by many users as a > feature. It that "feature" is broken in a small number of cases then a > proper programmer would fix that broken feature and not advocate for its > removal just because it is more convenient than developing a fix. >
You do realize you just went from comparing "billions" and how supposedly an overwhelming majority would be upset, to "some people". And even within that intersection of audiences, you would never be able to convince anybody here, that for some reason John Doe would declare a constant as FOO, but then use it as Foo. I believe I've made my point. Please stop with the non-sense comparisons, and talk about *constants in PHP*. Cheers, Andrey.
  100621
September 15, 2017 11:13 TonyMarston@hotmail.com ("Tony Marston")
"Andrey Andreev"  wrote in message 
news:CAPhkiZxdVwiEDOW9XZfcADV+o1UC=SG_pc2Nw7NqU1W_gV8bNg@mail.gmail.com...
> >Hi again, > >On Fri, Sep 15, 2017 at 12:46 PM, Tony Marston <TonyMarston@hotmail.com> >wrote: >> "Andrey Andreev" wrote in message >> news:CAPhkiZyXgxi-7vWdqA2hxni9SvycuN_pWOOM8un8mUo5qJ=0jg@mail.gmail.com... >>> >>> >>> Hi, >>> >>> On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston <TonyMarston@hotmail.com> >>> 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? >> >> >> How many people in the world work with PCs running Microsoft Windows? >> More >> than those running alternatives. >> > >So you admit that you just made up the number?
Can you show me any statistics which prove otherwise?
>>> And how many of them have ever encountered case-sensitivity as a >>> concept? >> >> >> None, because they have always used case-insensitive software. >> > >And that will not change, regardless of how PHP constants work. Thus, >re-inforcing my point - that you're completely off-topic. > >>> 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? >> >> >> When searching for a file in Windows it is not necessary to now what case >> it >> was created in. When searching for a word in a file it is not necessary >> to >> now what case it was created in. TRy taking that ability away from >> Windows >> users and see what reaction you get. >> > >1. Search is a feature that goes way beyond case-sensitivity, and that >was not what I was (rhetorically) asking. >2. Unless Windows users search for filenames matching constants >declared in PHP code, this is irrelevant. > >>> Also, are we Microsoft developers? Are we trying to change Windows? >> >> >> No, but you are suggesting a change from being consistent with Windows to >> being inconsistent. >> > >It *happens* to be consistent; nobody has ever cared about whether it is or >not. >And I am not suggesting anything. I am simply pointing out the >ridiculous false-equivalences you're making. > >>> And most importantly: How do everyday Windows users have anything to >>> do with PHP developers? >> >> >> Some people are also Windows users as well as PHP developers, and if >> those >> people are told that some of the software which they use is now being >> switched from being case-insensitive to case-sensitive just because the >> programmers cannot solve a small problem which only affects a small >> number >> of character sets, then those people will not be happy. Case-insensitive >> software has been around for decades and is regarded by many users as a >> feature. It that "feature" is broken in a small number of cases then a >> proper programmer would fix that broken feature and not advocate for its >> removal just because it is more convenient than developing a fix. >> > >You do realize you just went from comparing "billions" and how >supposedly an overwhelming majority would be upset, to "some people". >And even within that intersection of audiences, you would never be >able to convince anybody here, that for some reason John Doe would >declare a constant as FOO, but then use it as Foo. > >I believe I've made my point. Please stop with the non-sense >comparisons, and talk about *constants in PHP*.
You may think that this issue is limited to constants but others do not. Someone (not me) said that if constants were to be made case sensitive then the rest of the language should follow suit "just to be consistent". Someone else (not me) pointed to a bug regarding case switching when using the Turkish character set. It was suggested that one way to resolve this issue would be to avoid case switching altogether by making everything case sensitive. I suggest you look at Levi Morrison's post dated 14/09/2017 @ 17:02 which said: "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." My argument is that far too many people have become used to case insensitive software, and to remove this "feature" for no other reason than the programmers involved would find it "more convenient" to remove the feature altogether rather than make the effort in implementing a proper solution would go down like a ton of bricks with all those users. -- Tony Marston
  100622
September 15, 2017 12:31 lester@lsces.co.uk (Lester Caine)
On 15/09/17 12:13, Tony Marston wrote:
> My argument is that far too many people have become used to case > insensitive software, and to remove this "feature" for no other reason > than the programmers involved would find it "more convenient" to remove > the feature altogether rather than make the effort in implementing a > proper solution would go down like a ton of bricks with all those users.
case-insensitive only works reliably for an ascii character set. This is what the vast majority of PROGRAMMERS expect to see. Even Microsoft 16bit subset of unicode characters can not RELIABLY be upper or lower cased, but add the full unicode set and the conflicts of the number of characters required for one or other conversion explains why a conversion to unicode in the core proved impractical. The main point here is that it may be ESSENTIAL to introduce a switch to case sensitive if we are also to convert to full unicode support. The alternative is to restrict the character set back to ascii for all programming operations if case-insensitivity is to be retained. And how many of you have hit the problem of Windows supplying a CamelCase version of a file name when it was entered lower case. Since all our web servers are 'non-windows', hitting the idiosyncrasies of these inappropriate case conversions just adds to the fun. That may not the happening these days, but cause major problems at one time! -- 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
  100630
September 15, 2017 14:48 TonyMarston@hotmail.com ("Tony Marston")
"Lester Caine"  wrote in message 
news:d97cd2e5-bd5b-4c9f-2c20-107560d5a2e5@lsces.co.uk...
> >On 15/09/17 12:13, Tony Marston wrote: >> My argument is that far too many people have become used to case >> insensitive software, and to remove this "feature" for no other reason >> than the programmers involved would find it "more convenient" to remove >> the feature altogether rather than make the effort in implementing a >> proper solution would go down like a ton of bricks with all those users. > >case-insensitive only works reliably for an ascii character set. This is >what the vast majority of PROGRAMMERS expect to see. Even Microsoft >16bit subset of unicode characters can not RELIABLY be upper or lower >cased, but add the full unicode set and the conflicts of the number of >characters required for one or other conversion explains why a >conversion to unicode in the core proved impractical.
It may be impractical for lazy programmers, but it is not impossible. While unicode can comfortably deal with one-to-one case mappings, it does provide the means to specify one-to-many case mappings and other special cases. All it needs is for all these special cases to be identified and the "problem" is alleviated.
> The main point >here is that it may be ESSENTIAL to introduce a switch to case sensitive >if we are also to convert to full unicode support. The alternative is to >restrict the character set back to ascii for all programming operations >if case-insensitivity is to be retained.
Good idea. If certain characters cause problems when switching case then those characters should be banned.
>And how many of you have hit the problem of Windows supplying a >CamelCase version of a file name when it was entered lower case.
I haven't, but I always take the precaution of downshifting all file names in order to avoid problems with that PITA called unix/linux.
> Since >all our web servers are 'non-windows', hitting the idiosyncrasies of >these inappropriate case conversions just adds to the fun. That may not >the happening these days, but cause major problems at one time!
There are still inconsistencies when different browsers render the same HTML, CSS or Javascript differently. -- Tony Marston
  100616
September 15, 2017 09:34 addw@phcomp.co.uk (Alain Williams)
On Fri, Sep 15, 2017 at 09:51:53AM +0100, Tony Marston wrote:

> >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.
Not possible - see below.
> I don't give two hoots what javascript does.
Many PHP programmers also write Javascript. Avoiding gratuitous inconsistencies will help them.
> 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?
I don't think that you understand Unicode. Case mapping is not as simple as you seem to think - even in English. For a start there are 3 cases: lower, upper & title. It then gets more complicated. I suggest that you read: http://unicode.org/faq/casemap_charprop.html -- 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
  100626
September 15, 2017 14:25 TonyMarston@hotmail.com ("Tony Marston")
"Alain Williams"  wrote in message 
news:20170915093457.GI8096@phcomp.co.uk...
> >On Fri, Sep 15, 2017 at 09:51:53AM +0100, Tony Marston wrote: > >> >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. > >Not possible - see below. > >> I don't give two hoots what javascript does. > >Many PHP programmers also write Javascript. Avoiding gratuitous >inconsistencies >will help them. > >> 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? > >I don't think that you understand Unicode. Case mapping is not as simple as >you >seem to think - even in English. For a start there are 3 cases: lower, >upper & >title. It then gets more complicated. I suggest that you read: > >http://unicode.org/faq/casemap_charprop.html
I have read that article, and while it says that case switching may not be easy it does not say that it is impossible. While most case mappings work on a one-to-one basis it is possible to specify any one-to-any mappings as well as any additional mappings used in case folding for any exceptions. -- Tony Marston