Welcome! Log In Create A New Profile

Advanced

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

Posted by Christoph M. Becker 
Alain Williams
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 11:40AM
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 <std_disclaimer.h>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 11:50AM
"Andrey Andreev" wrote in message
news:[email protected]om...
>
>Hi,
>
>On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston <[email protected]>
>wrote:
>>
>>> Far better that that
>>> problem is taken away from the file system (which should be clean,
>>> robust
>>> and
>>> fast) and if you want case independence put it up at the application
>>> layer.
>>
>>
>> You try telling that to the billions of Windows users who have been used
>> to
>> a case insensitive file system for decades. Not to mention all Microsoft
>> software which is case insensitive. Try to take that away and billions of
>> users will be baying for your blood.
>>
>
>Billions? Do we have that statistic available?

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 <[email protected]>
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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 15.09.2017 um 11:25 schrieb Tony Marston:
> You are missing a third option - Microsoft languages are
> case-preserving. This is where the IDE ensures that every use of a word
> is automatically switched to the case used in its original definition.
> This makes it impossible to use the same word with a different case.

a sane IDE for PHP does exactly the same for many many years if you
don't insist to change it manually - when you manage that you functions
are written all over your codebase with different uppercase/lowercase
the problem is looking at you from a mirror every morning

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

On Fri, Sep 15, 2017 at 12:46 PM, Tony Marston <[email protected]> wrote:
> "Andrey Andreev" wrote in message
> news:[email protected]om...
>>
>>
>> Hi,
>>
>> On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston <[email protected]>
>> wrote:
>>>
>>>
>>>> Far better that that
>>>> problem is taken away from the file system (which should be clean,
>>>> robust
>>>> and
>>>> fast) and if you want case independence put it up at the application
>>>> layer.
>>>
>>>
>>>
>>> You try telling that to the billions of Windows users who have been used
>>> to
>>> a case insensitive file system for decades. Not to mention all Microsoft
>>> software which is case insensitive. Try to take that away and billions of
>>> users will be baying for your blood.
>>>
>>
>> Billions? Do we have that statistic available?
>
>
> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 01:20PM
"Andrey Andreev" wrote in message
news:[email protected]om...
>
>Hi again,
>
>On Fri, Sep 15, 2017 at 12:46 PM, Tony Marston <[email protected]>
>wrote:
>> "Andrey Andreev" wrote in message
>> news:[email protected]om...
>>>
>>>
>>> Hi,
>>>
>>> On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston <[email protected]>
>>> wrote:
>>>>
>>>>
>>>>> Far better that that
>>>>> problem is taken away from the file system (which should be clean,
>>>>> robust
>>>>> and
>>>>> fast) and if you want case independence put it up at the application
>>>>> layer.
>>>>
>>>>
>>>>
>>>> You try telling that to the billions of Windows users who have been
>>>> used
>>>> to
>>>> a case insensitive file system for decades. Not to mention all
>>>> Microsoft
>>>> software which is case insensitive. Try to take that away and billions
>>>> of
>>>> users will be baying for your blood.
>>>>
>>>
>>> Billions? Do we have that statistic available?
>>
>>
>> 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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 02:40PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lester Caine
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 02:50PM
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

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

>> <?php
>> define('FOO', true, true); // public const in ext; transcript from C
>> const FOO = false; // in global app code
>>
>> Why doesn't that fail? How am I supposed to write the extension
>
> It should fail, but that's not what we're discussing here.

I think it is, see https://bugs.php.net/bug.php?id=75211.

> If you say that everybody already used CONST_CS then great. I
> see however that some extensions (e.g. ibase and mcrypt) do not use that
> flag.

Thanks for pointing out my mistake. I had a closer look and indeed
found that ext/interbase defines case-insensitive constants throughout.
The only other case-insensitive constants defined in a recent php-src
master seem to be TRUE, FALSE, NULL and SID.

With regard to mcrypt and interbase: the former has been deprecated as
of PHP 7.1.0[1], and the latter had originally been suggested for
removal as of PHP 7.0.0, but a maintainer stepped forward and so the
extension has been kept, but apparently they don't have the time to
maintain the extension anymore[2]. It seems to me that users of these
extensions have bigger issues than changing the case of the constants
(if this would even be necessary; they may well already have written
these in upper case).

And of course, there may be many more extensions defining
case-insensitive constants, and it appears to be practically impossible
to assess the resulting BC break if we remove this option. However, I'm
not suggesting to remove it right away, but rather to deprecate
case-insensitive constants first. Any peace of software that is
actively maintained should be able to cope with this change during the
course of some years.

Anyhow, sticking with the possibility to define case-insensitive
constants in extensions, but to remove the third parameter of define()
wouldn't help at all.

[1] https://wiki.php.net/rfc/mcrypt-viking-funeral
[2] https://bugs.php.net/bug.php?id=72175

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 04:20PM
"Alain Williams" wrote in message
news:[email protected]
>
>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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 04:30PM
"Alain Williams" wrote in message
news:[email protected]
>
>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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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!

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 04:40PM
wrote in message news:[email protected]
>
>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 <[email protected]>
>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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 15.09.2017 um 16:38 schrieb Tony Marston:
> wrote in message news:[email protected]
>>
>> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 05:00PM
"Lester Caine" wrote in message
news:[email protected]
>
>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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 05:00PM
"Lester Caine" wrote in message
news:[email protected]
>
>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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 15, 2017 05:00PM
wrote in message news:[email protected]
>
>
>
>Am 15.09.2017 um 11:25 schrieb Tony Marston:
>> You are missing a third option - Microsoft languages are case-preserving.
>> This is where the IDE ensures that every use of a word is automatically
>> switched to the case used in its original definition. This makes it
>> impossible to use the same word with a different case.
>
>a sane IDE for PHP does exactly the same for many many years if you don't
>insist to change it manually - when you manage that you functions are
>written all over your codebase with different uppercase/lowercase the
>problem is looking at you from a mirror every morning

How many IDEs out there for PHP? What percentage of them support case
preserving? Zend Studio didn't when I used it. PHPEd doesn't.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 15.09.2017 um 16:58 schrieb Tony Marston:
> wrote in message news:[email protected]
>>
>> Am 15.09.2017 um 11:25 schrieb Tony Marston:
>>> You are missing a third option - Microsoft languages are
>>> case-preserving. This is where the IDE ensures that every use of a
>>> word is automatically switched to the case used in its original
>>> definition. This makes it impossible to use the same word with a
>>> different case.
>>
>> a sane IDE for PHP does exactly the same for many many years if you
>> don't insist to change it manually - when you manage that you
>> functions are written all over your codebase with different
>> uppercase/lowercase the problem is looking at you from a mirror every
>> morning
>
> How many IDEs out there for PHP? What percentage of them support case
> preserving? Zend Studio didn't when I used it. PHPEd doesn't

i need to see one which don't make autocompletion with preserved case
and if you don't use it because you like typos in general your fault

again: it's no rocket science to throw at compile time deprecation
warnings years before a final change is planned and so for sloppy legacy
code you hav enot more to do than read your error logs

after i switched every piece of code i write the last 15 years tpo
strict-types, typhe-hints and return-types everywhere while also write a
complete autotest suite you can't tell me it costs more time to fix such
case warnings by read the log and it would take longer as all your
discussions - so why don't you stop it?


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yasuo Ohgaki
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 16, 2017 05:30AM
Hi Christoph,

On Tue, Sep 12, 2017 at 10:04 PM, Christoph M. Becker <[email protected]>
wrote:

> On 12.09.2017 at 14:52, François Laupretre wrote:
>
> > What about making PHP 8 100% case-sensitive (except true/false) ? If we
> > announce it years in advance, it is possible, IMO.
>
> I don't think we can do that. Consider, for instance, ext/gd where all
> functions are actually in lower case, but I've seen a lot of code
> written in pascal or camel case to make the functions better readable, e.g.
>
> imageCreateFromJpeg() vs. imagecreatefromjpeg()
>

Consistent function names at the same time, perhaps?
https://wiki.php.net/rfc/consistent_function_names

--
Yasuo Ohgaki
yohgaki@ohgaki.net
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 16, 2017 11:00AM
"Rowan Collins" wrote in message
news:[email protected]
>
>On 14 September 2017 10:23:48 BST, Tony Marston
>>Would this problem disappear by using UTF8 instead of the Turkish
>>character
>>set? If so then ten no other solution would be required.
>
>No, the problem has nothing to do with character sets, but with the actual
>alphabet that humans in Turkey use, which doesn't follow the same rules as
>the alphabet that American humans use.
>
>Unicode (the standard, not the character set or any of its encodings) has
>an algorithm / lookup table for "case folding", because "convert everything
>to lower case" is not a reliable way to produce case insensitive
>comparisons. Using that correctly world presumably solve this particular
>problem.
>
>The bottom line is that case sensitive comparisons are easier than case
>insensitive ones.

A programmer's job is to write software which makes life easier for his
users, not to remove features which his users are used to just because it is
"more convenient" for him.

While the vast majority of characters in any character set have a one-to-one
mapping between upper and lower case, there are exceptions. I have been
writing software for several decades, and I have come to know the 80-20 rule
which states that 80% of the code is for "normal" circumstances while 20% is
for the exceptions, yet coding for the "normal" circumstances takes 20% of
the effort while the exceptions require 80%. It is the programmer's job to
deal with these exceptions, so to say that it's not going to be done because
it is not easy is a very poor excuse.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 16, 2017 11:20AM
wrote in message news:[email protected]
>
>
>
>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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 16, 2017 11:40AM
wrote in message news:[email protected]
>
>
>
>Am 15.09.2017 um 16:38 schrieb Tony Marston:
>> wrote in message news:[email protected]
>>>
>>> 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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 16, 2017 11:40AM
wrote in message news:[email protected]
>
>
>
>Am 15.09.2017 um 16:58 schrieb Tony Marston:
>> wrote in message news:[email protected]
>>>
>>> Am 15.09.2017 um 11:25 schrieb Tony Marston:
>>>> You are missing a third option - Microsoft languages are
>>>> case-preserving. This is where the IDE ensures that every use of a word
>>>> is automatically switched to the case used in its original definition.
>>>> This makes it impossible to use the same word with a different case.
>>>
>>> a sane IDE for PHP does exactly the same for many many years if you
>>> don't insist to change it manually - when you manage that you functions
>>> are written all over your codebase with different uppercase/lowercase
>>> the problem is looking at you from a mirror every morning
>>
>> How many IDEs out there for PHP? What percentage of them support case
>> preserving? Zend Studio didn't when I used it. PHPEd doesn't
>
>i need to see one which don't make autocompletion with preserved case and
>if you don't use it because you like typos in general your fault

You are avoiding the question. You state that dealing with this situation
should be done within the IDE, so my question is how any PHP IDEs actually
support this feature?

If your answer to this question is another question - how any don't support
this feature? - then my answer is "none of them". Unless you can prove
otherwise, of course.

>again: it's no rocket science to throw at compile time deprecation warnings
>years before a final change is planned and so for sloppy legacy code you
>hav enot more to do than read your error logs
>
>after i switched every piece of code i write the last 15 years tpo
>strict-types, typhe-hints and return-types everywhere while also write a
>complete autotest suite you can't tell me it costs more time to fix such
>case warnings by read the log and it would take longer as all your
>discussions - so why don't you stop it?

Just because you disagree with what I have to say does not mean that you can
tell me to stop saying it. If you want me to accept that you can have a
different opinion then you should extend the same courtesy to me.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Alain Williams
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 16, 2017 11:50AM
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 <std_disclaimer.h>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 16.09.2017 um 11:36 schrieb Tony Marston:
> wrote in message news:[email protected]
>> after i switched every piece of code i write the last 15 years tpo
>> strict-types, typhe-hints and return-types everywhere while also write
>> a complete autotest suite you can't tell me it costs more time to fix
>> such case warnings by read the log and it would take longer as all
>> your discussions - so why don't you stop it?
>
> Just because you disagree with what I have to say does not mean that you
> can tell me to stop saying it. If you want me to accept that you can
> have a different opinion then you should extend the same courtesy to me.
you statet your opinion often enough as you did in the thread where you
explained us that code consistency don't matter for you - in both cases
nobody agreed

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 16, 2017 12:00PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 16, 2017 12:50PM
wrote in message news:[email protected]
>
>
>
>Am 16.09.2017 um 11:36 schrieb Tony Marston:
>> wrote in message news:[email protected]
>>> after i switched every piece of code i write the last 15 years tpo
>>> strict-types, typhe-hints and return-types everywhere while also write a
>>> complete autotest suite you can't tell me it costs more time to fix such
>>> case warnings by read the log and it would take longer as all your
>>> discussions - so why don't you stop it?
>>
>> Just because you disagree with what I have to say does not mean that you
>> can tell me to stop saying it. If you want me to accept that you can have
>> a different opinion then you should extend the same courtesy to me.

>you stated your opinion often enough as you did in the thread where you
>explained us that code consistency don't matter for you - in both cases
>nobody agreed

Consistency with what? Why should I change the way that I code just to be
consistent with somebody else's bad decisions? Why should I have to take
someone else's personal preferences and treat them as if they were cast in
stone and handed down from the mountain top?

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 16, 2017 01:00PM
"Alain Williams" wrote in message
news:[email protected]
>
>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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 16, 2017 01:00PM
""Christoph M. Becker"" wrote in message
news:[email protected]
>
>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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski
RE: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 16, 2017 05:10PM
> -----Original Message-----
> From: Christoph M. Becker [mailto:[email protected]]
> Sent: Tuesday, September 12, 2017 3:03 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Deprecate and remove case-insensitive constants?
>
> Hi everybody!
>
> Usually constant identifiers are treated case-sensitive in PHP. This is always
> the case for constants defined via a `const` declaration.
> However, define() allows to pass TRUE as third argument to define a case-
> insensitive constant. This feature appears to potentially result in confusion,
> and also causes bugs as shown in https://bugs.php.net/74450. See an
> example created by Nikita to see some probably unexpected behavior:
> https://3v4l.org/L6nCp.
>
> Even if these issues could be resolved, I still think allowing both case-
> sensitive and case-insensitive constant identifiers does more harm than
> good, so either case-sensitive or case-insensitive constant identifiers should
> be removed from the language. Since case-sensitive constant identifiers are
> already the default, and HHVM doesn't even support case-insensitive
> identifiers at all, I would suggest to remove case-insensitive constant
> identifiers.

Even though I don't think it's the end of the world if we remove case insensitive constants, I think there are a few things to consider.

First, in the example referenced above, arguably, making all constants case insensitive would in fact be the better solution - as you likely don't want both sOmE_CoNsT and SOME_CONST, or more reaslitically - Some_Const and SOME_CONST to both exist in your app - a situation case sensitive constants would happily let you do. That said, I think the scenario of having two define()'s, both define the same constant with different casing is such an edge case we really shouldn't put too much emphasis on it.

Which brings me to the second thing - deprecating features - even if they aren't the best features in the world - should only be considered if there's very substantial gain to be had. Breaking compatibility has substantial cost on our users, and consequently - on the PHP project. While sometimes breaking compatibility is warranted - for security, reliability or performance - it is, in general, something we ought to do our best to avoid if there isn't a strong case for it.

Does deprecating case insensitive constants clear the bar of 'substantial gains to be had'? Personally, I don't think so. Yes, a marginal edge case that took almost 20 years to surface would become marginally better (and that edge case is arguably better served by deprecating case sensitive constants) - but in my opinion, that hardly clears the bar for the 'substantial gains to be had'. The marginal simplification to the engine is unlikely to bring big news either - it's not as if we've been investing tons of cycles on maintaining that part of the code anyway (FWIW, in response to #74450 I would simply state that defining overlapping case sensitive and case insensitive constants results in undefined behavior - I wouldn't try to solve it, it is as edgy as edge cases get).

If I had to guess, in the vast accumulated PHP code base out there - the majority of which is outside our reach to review, constants defined as SOME_CONST and used as Some_Const (or some_const, or vice versa) are most probably out there (e.g. in situations when the author of a library prefers one type of casing and the application author prefers another). Not a major issue, we'll survive this if this deprecation goes through, but we will also survive just fine if it doesn't - and the likely net effect on our userbase would be less negative.

My 2c.

Zeev
Sorry, only registered users may post in this forum.

Click here to login