Welcome! Log In Create A New Profile

Advanced

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

Posted by Christoph M. Becker 
Levi Morrison
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 16, 2017 05:30PM
> 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.

This argument holds no water in my eyes.

1) Can you tell the difference between YEAR and ΥEAR? I can't. That's
a Greek Capital Letter Upsilon, not a capital ASCII Y, in the latter.
This situation is worse and irreconcilable. People do this sort of
thing from time to time as obfuscation or for clever debugging
puzzles. It's not really an issue in practice because it's confusing
and so people avoid it.

2) sOmE_CoNsT would be absolutely terrible to type over and over.
Nobody will want to subject themselves to it. It might be done from
time to time just like the unicode abuse.

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

With all I've said I still agree here. Deprecating case-insensitive
constants *by itself* is not a substantial gain. This is why I opened
with my very first reply in this thread on a note of combining it with
other features that *would* be substantial. However, other people have
really wanted us to focus the discussion on deprecating case
insensitive constants only, and if that's what we do I'll be voting
"no". However it is something I really would like to see in connection
with other features or changes.

--
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 06:40PM
> -----Original Message-----
> From: morrison.levi@gmail.com [mailto:[email protected]] On Behalf
> Of Levi Morrison
> Sent: Saturday, September 16, 2017 6:25 PM
> To: Zeev Suraski <[email protected]>
> Cc: Christoph M. Becker <[email protected]>; internals@lists.php.net
> Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
>
> > 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.
>
> This argument holds no water in my eyes.
>
> 1) Can you tell the difference between YEAR and ΥEAR? I can't. That's a Greek
> Capital Letter Upsilon, not a capital ASCII Y, in the latter.
> This situation is worse and irreconcilable. People do this sort of thing from
> time to time as obfuscation or for clever debugging puzzles. It's not really an
> issue in practice because it's confusing and so people avoid it.

I'm genuinely not sure how it's related to what I said. If someone is a 'clever' developer trying to intentionally obfuscate their code, good luck to them. PHP shouldn't try to stop them. We shouldn't care about these cases - not care a bit, but not at all.

> 2) sOmE_CoNsT would be absolutely terrible to type over and over.
> Nobody will want to subject themselves to it. It might be done from time to
> time just like the unicode abuse.

True, but here too, I'm not sure how it's related to what I said.
The only relevance I can think of is if you think sOmE_CoNsT is something I came up with and is my idea of coding, and it's not - it's taken from the bug that got this all thread started in the first place (bugs.php.net/bug.php?id=74450). A more realistic case would be SOME_CONST, Some_Const and some_const, used interchangeably within a multi-layered app. I can totally imagine someone consistently using Some_Const everywhere, while the definition was for SOME_CONST.

> > 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.
>
> With all I've said I still agree here. Deprecating case-insensitive constants *by
> itself* is not a substantial gain. This is why I opened with my very first reply in
> this thread on a note of combining it with other features that *would* be
> substantial. However, other people have really wanted us to focus the
> discussion on deprecating case insensitive constants only, and if that's what
> we do I'll be voting "no". However it is something I really would like to see in
> connection with other features or changes.

Fair enough, but for now I'm focusing on the original proposal.

Zeev
Sara Golemon
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 16, 2017 08:20PM
On Sat, Sep 16, 2017 at 11:04 AM, Zeev Suraski <[email protected]> wrote:
> arguably, making all constants case insensitive
> would in fact be the better solution
>
If they were truly case-insensitive, I might agree. However, as I've
mentioned but will reiterate, they're not. They're ASCII case
insensitive, and that's a long cry from real case-insensitivity. PHP
6 was planning to make case-insensitivity real but obviously that's
dead and buried.

This is ugly, but if I'm playing devil's advocate, it is consistent
with the rest of the core runtime.

-Sara

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

> 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

We could fix that case by banning different-case definitions for CI
constants. That's probably right thing to do - probability that it is
not a bug in the code is very near to zero.
--
Stas Malyshev
smalyshev@gmail.com

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

> If they were truly case-insensitive, I might agree. However, as I've
> mentioned but will reiterate, they're not. They're ASCII case
> insensitive, and that's a long cry from real case-insensitivity. PHP
> 6 was planning to make case-insensitivity real but obviously that's
> dead and buried.

Should we really go there then? Full Unicode support for these things is
probably not going to happen, and I'd argue not many people actually
need it. Like it or not, it is not super-common to write PHP function
names or constant names in Russian, Farsi or hiragana. It demoes nice,
but I'm not sure that is a primary feature people would seek.

> This is ugly, but if I'm playing devil's advocate, it is consistent
> with the rest of the core runtime.

Frankly, I'd be fine with either - provided that we don't have more than
one kind (i.e. if we allow case-insensitive constants, no defining both
FOO and Foo).
But for cases-sensitivity I am worried about BC impact. We do have a
bunch of CI constants in extensions, including such widely used modules
as mcrypt. I'm not sure people use it in different cases, but hard to
really know... Maybe with suitable deprecation step it'd be OK, but not
sure how to make it work for CI constants.

--
Stas Malyshev
smalyshev@gmail.com

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

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

Thanks to everybody for their comments on this topic!

Frankly, I'm rather surprised about the large amount of objections – I
just hadn't expected that. Now I'm pretty sure that a respective change
wouldn't get broad consensus, and in my opinion broad consensus is of
utmost importance regarding any change to php-src. Therefore I will not
pursue the RFC. :)

Sorry for the noise, if you regard this discussion as such. I, however,
found it insightful, and learned a lot about case-insensitive constants,
and I believe these lessions to be useful at least for me.

So, thanks again!

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 16/09/17 11:56, Tony Marston wrote:
> ""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.
>
Try China vs. china
One is a country, the other is a type of ceramic.

--
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 18, 2017 11:50AM
"niel" wrote in message
news:[email protected]
>
>On 16/09/17 11:56, Tony Marston wrote:
>> ""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.
>>
>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


--
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 18, 2017 12:50PM
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

--
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 19, 2017 11:30AM
""Christoph M. Becker"" wrote in message
news:[email protected]
>
>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


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




--
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 20, 2017 11:40AM
wrote in message news:[email protected]
>
>
>
>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
Lester Caine
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 20, 2017 12:10PM
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

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

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

> wrote in message news:[email protected]
>
>>
>>
>>
>> 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
>
>
Tony Marston
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 22, 2017 10:30AM
wrote in message news:[email protected]
>
>
>
>Am 20.09.2017 um 11:30 schrieb Tony Marston:
>> wrote in message news:[email protected]
>>>
>>>
>>>
>>> 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

Just because my opinion differs from yours does not give you the right to
demand that I stop expressing it.

To me the situation is quite simple.
- Human beings have grown accustomed to case-insensitive world, and to
remove this standard feature would cause great disruption.
- Some people may think that function names written as "do_something" or
"do_Something" or "Do_Something" which mean the same thing are wrong, but
that is no more than simply irritating for the nit-picking minority. If you
made those names mean different thing then that would be worse than wrong,
it would be criminally insane.
- Rather than making constants case sensitive it would be better to leave
then as case insensitive, but prevent the creation of a constant with the
same name but different case. This would make it consistent with function
and method names.
- If the use of some non-ASCII characters in function names causes case
folding problems then I see two choices - either disallow non-ASCII
characters in function names, or allow Unicode characters but disallow any
which have case folding problems.

Simply telling me that it would be easier to make the entire language case
sensitive as there are "difficulties" with case folding of a minute number
of unicode characters is not good enough. Programmers are supposed to solve
problems for their users, not create them.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 22.09.2017 um 10:21 schrieb Tony Marston:
> wrote in message news:[email protected]
>>>> 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
>
> Just because my opinion differs from yours does not give you the right
> to demand that I stop expressing it

surely, in my opinion you don't understand the topic you are talking
about and repeating the same questionable stuff again and again and as
you are allowed to express your opinion i am allowed to express mine

the way you argued about how code consistency don't matter says it all
as you call everybody which demands that code all over a poject or
company has to follow a common coding style "OCD sufferers" - but hey,
the others are all ghost drivers and should turn around....

--
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 24, 2017 11:40AM
wrote in message news:[email protected]
>
>
>
>Am 22.09.2017 um 10:21 schrieb Tony Marston:
>> wrote in message news:[email protected]
>>>>> 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
>>
>> Just because my opinion differs from yours does not give you the right to
>> demand that I stop expressing it
>
>surely, in my opinion you don't understand the topic you are talking about
>and repeating the same questionable stuff again and again and as you are
>allowed to express your opinion i am allowed to express mine
>
>the way you argued about how code consistency don't matter says it all

It is your definition of "consistency" that I object to. Consistency with
what? Code that abandons case insensitivity "just to be consistent" is
consistently bad because it removes the feature called "case insensitivity"
that we humans have become used to since we began to read and write. I have
been working in the computer industry since the early 1970s on a variety of
mainframe, mini- and micro-computers, and a variety of languages. and this
was all case insensitive. It was only the invention of unix which threw a
spanner in the works.

>as you call everybody which demands that code all over a poject or company
>has to follow a common coding style "OCD sufferers" - but hey, the others
>are all ghost drivers and should turn around....

If you wish to enforce case sensitivity in projects which you control then
go ahead. Just don't try to enforce it on everybody else.

--
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 24, 2017 12:10PM
On Sun, Sep 24, 2017 at 10:36:02AM +0100, Tony Marston wrote:

> we began to read and write. I have been working in the computer
> industry since the early 1970s on a variety of mainframe, mini- and
> micro-computers, and a variety of languages. and this was all case
> insensitive. It was only the invention of unix which threw a spanner
> in the works.

I remember those early days; things have changed. Back then case was not an issue:

* ASR33 Teletypes were upper case only

* Punch cards machines were upper case only

Yes: you could sometimes get lower case, but it was hard.

Case conversion was easy:

* ASCII - 7 bit characters, easy

* EBCDIC - 8 bit characters, easy

(OK: national variants of ASCII/EBCDIC, but still 7/8 bit).

Some machines, eg CDC, had 6 bit character set - upper case only.

These days we use Unicode, a 21 bit character set. Case conversion is hard and,
as others have explained, can be ambiguous, non-reversible, ...

> If you wish to enforce case sensitivity in projects which you
> control then go ahead. Just don't try to enforce it on everybody
> else.

May I suggest that you create your own fork of PHP and leave the rest of us alone.

--
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 24.09.2017 um 11:36 schrieb Tony Marston:
> wrote in message news:[email protected]
>> Am 22.09.2017 um 10:21 schrieb Tony Marston:
>>> wrote in message news:[email protected]
>>>>>> 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
>>>
>>> Just because my opinion differs from yours does not give you the
>>> right to demand that I stop expressing it
>>
>> surely, in my opinion you don't understand the topic you are talking
>> about and repeating the same questionable stuff again and again and as
>> you are allowed to express your opinion i am allowed to express mine
>>
>> the way you argued about how code consistency don't matter says it all
>
> It is your definition of "consistency" that I object to. Consistency
> with what? Code that abandons case insensitivity "just to be consistent"
> is consistently bad because it removes the feature called "case
> insensitivity" that we humans have become used to since we began to read
> and write. I have been working in the computer industry since the early
> 1970s on a variety of mainframe, mini- and micro-computers, and a
> variety of languages. and this was all case insensitive. It was only the
> invention of unix which threw a spanner in the works.
>
>> as you call everybody which demands that code all over a poject or
>> company has to follow a common coding style "OCD sufferers" - but hey,
>> the others are all ghost drivers and should turn around....
>
> If you wish to enforce case sensitivity in projects which you control
> then go ahead. Just don't try to enforce it on everybody else.

that thread was about the PHP core and NOT case-sensitive where you
called people "OCD sufferers" - so don't play stupid games here when
everybody can access the list archive or is knowing your attitude
anyways - you have lost that game

https://www.mail-archive.com/[email protected]/msg91537.html
https://www.mail-archive.com/[email protected]/msg91562.html

and frankly people like you arguing about code consistency are fired
here from one the to the next because theri inability to write well
cocumentend and readable quality code at all and they are instead coding
timebombs

it's one thing when you write your private crap but from the point you
want your code used by somebody else you have to play with that rules


--
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 24, 2017 01:00PM
On 24/09/17 11:05, Alain Williams wrote:
>> we began to read and write. I have been working in the computer
>> industry since the early 1970s on a variety of mainframe, mini- and
>> micro-computers, and a variety of languages. and this was all case
>> insensitive. It was only the invention of unix which threw a spanner
>> in the works.
> I remember those early days; things have changed. Back then case was not an issue:
>
> * ASR33 Teletypes were upper case only
>
> * Punch cards machines were upper case only
>
> Yes: you could sometimes get lower case, but it was hard.
>
> Case conversion was easy:
>
> * ASCII - 7 bit characters, easy
>
> * EBCDIC - 8 bit characters, easy
>
> (OK: national variants of ASCII/EBCDIC, but still 7/8 bit).
>
> Some machines, eg CDC, had 6 bit character set - upper case only.
>
> These days we use Unicode, a 21 bit character set. Case conversion is hard and,
> as others have explained, can be ambiguous, non-reversible, ...

That sums it up nicely Alain ...
Now the question is actually ... do we stay in the dark ages of single
byte character sets or do we move to fully embrace a current well
established and extensively used standard. Unicode has perhaps shirked
on the matter of 'case-insensitive' so there is no clean solution to
that today. That should not prevent the switch to unicode and other
threads such as the csv routines are now highlighting additional 'edge
cases' where unicode needs addressing, or kicking into the long grass of
extensions of mbstring? Maintaining 'case-insensitive' for single byte
character sets is an option, but then one needs to stay with that for
the whole code functionality? Allowing multibyte constant names with the
current limited sub-set of case conversion is just not sensible, but in
the absence of a clean unicode case folding/conversion which is the
sensible next step?

--
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
Alain Williams
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 24, 2017 02:10PM
On Sun, Sep 24, 2017 at 11:52:49AM +0100, Lester Caine wrote:

> That sums it up nicely Alain ...
> Now the question is actually ... do we stay in the dark ages of single
> byte character sets or do we move to fully embrace a current well
> established and extensively used standard. Unicode has perhaps shirked
> on the matter of 'case-insensitive' so there is no clean solution to
> that today. That should not prevent the switch to unicode and other
> threads such as the csv routines are now highlighting additional 'edge
> cases' where unicode needs addressing, or kicking into the long grass of
> extensions of mbstring? Maintaining 'case-insensitive' for single byte
> character sets is an option, but then one needs to stay with that for
> the whole code functionality? Allowing multibyte constant names with the
> current limited sub-set of case conversion is just not sensible, but in
> the absence of a clean unicode case folding/conversion which is the
> sensible next step?

We also need to think about how our decisions here affect how PHP is used; in
particular robustness, correctness, ... of code that people write. I believe
that one attribute of the mind of a good programmer is precision/exactness -
eschewing sloppyness. Thus if a function is written DoSomething() then it should
be spelled that way, not doSomething(), etc.

Also PHP programmers are likely to write Javascript - which is case sensitive.

I have also seen problems where someone has developed code using Microsoft SQL,
they are then asked to port it to a case sensitive database, eg MySQL**.

Or an application written on a case insensitive file system (Eg MS Windows) and
then try to deploy it on Linux: only to have includes & fopens fail because they
have been inconsistent in how they wrote file names. [[ I do not want to get
into a discussion about the rights/wrongs of case (in)sensitive file names - we
must just accept that as part of the world that we live in. ]]

So encouraging the ''names are case sensitive'' meme is, IMHO, good.

Then look at the internals of the PHP engine. Case insensitively adds
complexity (== places for bugs to lurk) and makes it slower - name lookup
happens a lot, it is not just a once off (& off line) compilation process. Some
of us work hard to make the PHP engine 0.5% faster - so why make it slower with
something that we can easily avoid ?

Yes: case insensitivity is nice, I have that option set in my program editor
search; but I am a programmer; to use PHP I have to put in a lot of effort to
learn how to do things -- the same is true for any programming language. We are
not talking about real end users such as my mother $$ - people who we try to
make our systems usable for without having to train them.

You ask what to do ?

I suggest that case insensitiveness in single byte character sets (constant &
function names) should be depricated, but enabled for one major release with an
init flag -- just as was done for register_globals. That would give everyone a
couple of years to tidy their code up.

Then kill case insensitve anything in PHP [[ other than the likes of
strcasecmp() ]].

**OK: MySQL has a switch to make table names, etc, case insensitive - but
enabling that means a lot of testing to ensure that nothing else breaks.

$$ I don't want to be rude about her, so maybe I ought to use a different group
of clueless people, politicians perhaps ? :-)

--
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
Sara Golemon
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 24, 2017 05:50PM
> Ad hominem ad infinitum...
>
Okay kids. You're both very big boys with reasons and arguments and
you're both clearly the smartest.
Now, how about we all respect that neither of you is going to convince
the other.

Any further bickering and name calling is just bickering and name calling.

Let's pretend we're adults.

-Sara

--
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 25, 2017 11:40AM
"Alain Williams" wrote in message
news:[email protected]
>
>On Sun, Sep 24, 2017 at 11:52:49AM +0100, Lester Caine wrote:
>
>> That sums it up nicely Alain ...
>> Now the question is actually ... do we stay in the dark ages of single
>> byte character sets or do we move to fully embrace a current well
>> established and extensively used standard. Unicode has perhaps shirked
>> on the matter of 'case-insensitive' so there is no clean solution to
>> that today. That should not prevent the switch to unicode and other
>> threads such as the csv routines are now highlighting additional 'edge
>> cases' where unicode needs addressing, or kicking into the long grass of
>> extensions of mbstring? Maintaining 'case-insensitive' for single byte
>> character sets is an option, but then one needs to stay with that for
>> the whole code functionality? Allowing multibyte constant names with the
>> current limited sub-set of case conversion is just not sensible, but in
>> the absence of a clean unicode case folding/conversion which is the
>> sensible next step?
>
>We also need to think about how our decisions here affect how PHP is used;
>in
>particular robustness, correctness, ... of code that people write. I
>believe
>that one attribute of the mind of a good programmer is
>precision/exactness -
>eschewing sloppyness. Thus if a function is written DoSomething() then it
>should
>be spelled that way, not doSomething(), etc.

It does absolutely no harm i different case is used. I agree that it is
wrong from a "purity" point of view, but it does NOT cause a genuine problem
(except in the minds of a few nit pickers). However, the solution that you
appear to support would definitely cause problems as we humans are used to
living in a case insensitive world:
- when we search for a word in a dictionary we do not have to specify the
exact case to get an exact match.
- when we search for a file on a user-friendly file system we do not have to
specify the exact case to find a match.
- when we search for a word inside a file we do not have to specify the
exact case to find a match. Some editors provide an option for a case
sensitive search, but the default is case INsensitive.

What do you think is going to happen when keyboard input is replaced by
voice input? Will we be able to just say a word, or will we have to spell it
out character by character in order to specify the case of each? Try selling
THAT idea and seehow far you get.

>Also PHP programmers are likely to write Javascript - which is case
>sensitive.

The fact that some languages are case sensitive is not a valid argument for
making all languages case sensitive. Most languages which came before
javascript were case insensitive, so perhaps it's time for javascript to
make itself consistent with those languages.

>I have also seen problems where someone has developed code using Microsoft
>SQL,
>they are then asked to port it to a case sensitive database, eg MySQL**.

MySQL is NOT case sensitive. I have been using it for nearly two decades,
and when I construct an SQL I can use either upper or lower case without any
problems.

>Or an application written on a case insensitive file system (Eg MS Windows)
>and
>then try to deploy it on Linux: only to have includes & fopens fail because
>they
>have been inconsistent in how they wrote file names. [[ I do not want to
>get
>into a discussion about the rights/wrongs of case (in)sensitive file
>names - we
>must just accept that as part of the world that we live in. ]]
>
>So encouraging the ''names are case sensitive'' meme is, IMHO, good.
>
>Then look at the internals of the PHP engine. Case insensitively adds
>complexity (== places for bugs to lurk) and makes it slower - name lookup
>happens a lot, it is not just a once off (& off line) compilation process.

Just because you cannot fix a feature which only causes a problem in a few
cases is no excuse to remove that feature completely.

> Some
>of us work hard to make the PHP engine 0.5% faster - so why make it slower
>with
>something that we can easily avoid ?

If keeping the language simple and fast is the objective, then why do I keep
seeing RFCs which propose ways of combining several simple functions into a
complex one just because the author wants to achieve something with fewer
keystrokes? Making the language more complicated for the benefit of a
minority, as well as creating code which is less readable, should be
something that is avoided, not promoted.

>Yes: case insensitivity is nice, I have that option set in my program
>editor
>search; but I am a programmer; to use PHP I have to put in a lot of effort
>to
>learn how to do things -- the same is true for any programming language. We
>are
>not talking about real end users such as my mother $$ - people who we try
>to
>make our systems usable for without having to train them.
>
>You ask what to do ?
>
>I suggest that case insensitiveness in single byte character sets (constant
>&
>function names) should be depricated, but enabled for one major release
>with an
>init flag -- just as was done for register_globals. That would give
>everyone a
>couple of years to tidy their code up.

Do you realise how much of a BC break this would be? For what benefit? Just
to satisfy your idea of "purity"?

>Then kill case insensitve anything in PHP [[ other than the likes of
>strcasecmp() ]].
>
>**OK: MySQL has a switch to make table names, etc, case insensitive - but
>enabling that means a lot of testing to ensure that nothing else breaks.
>
>$$ I don't want to be rude about her, so maybe I ought to use a different
>group
>of clueless people, politicians perhaps ? :-)
>

--
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 25, 2017 11:50AM
wrote in message news:[email protected]
>
>
>
>Am 24.09.2017 um 11:36 schrieb Tony Marston:
<snip>
>> If you wish to enforce case sensitivity in projects which you control
>> then go ahead. Just don't try to enforce it on everybody else.
>
>that thread was about the PHP core and NOT case-sensitive where you called
>people "OCD sufferers" - so don't play stupid games here when everybody can
>access the list archive or is knowing your attitude anyways - you have lost
>that game

The fact that some people write "do_something" or "do_Something" or
"Do_Something" or even "DO_SOMETHING" and it points to a single function
because of case insensitivity does NOT cause a genuine problem - except in
the minds of a few nit-picking, anal retentive OCD sufferers. The REAL
problem occurs when you make those four mixtures of case mean point to
different functions which do different things.

If you cannot tell the difference between a perceived problem and a real
problem your attempts to shut me up will continue to fail.

>https://www.mail-archive.com/[email protected]/msg91537.html
>https://www.mail-archive.com/[email protected]/msg91562.html
>
>and frankly people like you arguing about code consistency are fired here
>from one the to the next because theri inability to write well cocumentend
>and readable quality code at all and they are instead coding timebombs

I'm sorry, but reading code where the case of a word changes the meaning of
that word will make that code LESS readable, not MORE.

>it's one thing when you write your private crap but from the point you want
>your code used by somebody else you have to play with that rules

I repeat, if you want to enforce case sensitivity in those projects which
you control then go ahead, but don't try to enforce it on the whole
programming community.

--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 25.09.2017 um 11:41 schrieb Tony Marston:
> The fact that some people write "do_something" or "do_Something" or
> "Do_Something" or even "DO_SOMETHING" and it points to a single function
> because of case insensitivity does NOT cause a genuine problem - except
> in the minds of a few nit-picking, anal retentive OCD sufferers

wow - sue your dealer!

> I'm sorry, but reading code where the case of a word changes the meaning
> of that word will make that code LESS readable, not MORE

how comes when the same word is written over the whole codebase
*identically* that for it is harder to read?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
September 25, 2017 01:10PM
Tony, RH,

If you want to continue this debate, please can you take it off list.

Christoph announced that they're not pursuing their proposal nine days ago: https://marc.info/?l=php-internals&m=150559707900688&w=2 and since then the thread has become a rambling debate with no clear purpose.

As Sara says, I doubt either of you will change the other's mind, but if you want to keep trying, please do so privately.

Regards,

--
Rowan Collins
[IMSoP]

--
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 26, 2017 11:10AM
wrote in message news:[email protected]
>
>
>
>Am 25.09.2017 um 11:41 schrieb Tony Marston:
>> The fact that some people write "do_something" or "do_Something" or
>> "Do_Something" or even "DO_SOMETHING" and it points to a single function
>> because of case insensitivity does NOT cause a genuine problem - except
>> in the minds of a few nit-picking, anal retentive OCD sufferers
>
>wow - sue your dealer!
>
>> I'm sorry, but reading code where the case of a word changes the meaning
>> of that word will make that code LESS readable, not MORE
>
>how comes when the same word is written over the whole codebase
>*identically* that for it is harder to read?

That is not what I said. Taking the same function name and allowing
different versions to exist with different implementations would be a recipe
for disaster whereas the situation which you are complaining about is
nothing more than mildly annoying - except if you are a nit-picking, anal
retentive OCD sufferer in which case it signals the arrival of the four
horsemen of the apocalypse.

--
Tony Marston


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

Click here to login