Deprecate and remove case-insensitive constants?

François Laupretre

8 years ago

Hi,

Le 12/09/2017 à 14:02, Christoph M. Becker a écrit :

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

What about making PHP 8 100% case-sensitive (except true/false) ? If we
announce it years in advance, it is possible, IMO.

Regards

François

Christoph Becker

8 years ago

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

--
Christoph M. Becker

Dan Ackroyd

8 years ago

On 12 September 2017 at 14:04, Christoph M. Becker <cmbecker69@gmx.de> wrote:

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

It's pretty easy to imagine that if we had function autoloading,
creating an optional small backwards compatibility shim/library to
work around that problem would be pretty easy.

It's also the type of error that would be easy to add a deprecation
warning to in a late 7.x branch.

cheers
Dan

Yasuo Ohgaki

8 years ago

Hi Christoph,

On Tue, Sep 12, 2017 at 10:04 PM, Christoph M. Becker <cmbecker69@gmx.de>
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

Levi Morrison

8 years ago

On Tue, Sep 12, 2017 at 6:52 AM, François Laupretre
<francois@tekwire.net> wrote:

> Hi,
>
> Le 12/09/2017 à 14:02, Christoph M. Becker a écrit :
>>
>> Hi everybody!
>>
>> Usually constant identifiers are treated case-sensitive in PHP.  This is
>> always the case for constants defined via a `const` declaration.
>> However, define() allows to pass TRUE as third argument to define a
>> case-insensitive constant.  This feature appears to potentially result
>> in confusion, and also causes bugs as shown in
>> <https://bugs.php.net/74450>.  See an example created by Nikita to see
>> some probably unexpected behavior: <https://3v4l.org/L6nCp>.
>>
>> Even if these issues could be resolved, I still think allowing both
>> case-sensitive and case-insensitive constant identifiers does more harm
>> than good, so either case-sensitive or case-insensitive constant
>> identifiers should be removed from the language.  Since case-sensitive
>> constant identifiers are already the default, and HHVM doesn't even
>> support case-insensitive identifiers at all, I would suggest to remove
>> case-insensitive constant identifiers.
>>
>> This could be implemented by triggering E_DEPRECATED whenever the third
>> argument to define() is TRUE in PHP 7.3, and to remove this parameter
>> altogether in PHP 8.  Most likely some further simplification in the
>> engine could be done then as well.
>>
>> Thoughts?
>
>
> What about making PHP 8 100% case-sensitive (except true/false) ? If we
> announce it years in advance, it is possible, IMO.
>
> Regards
>
> François
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

By itself this change provides little value. If it was done in
connection with other features such as merging symbol tables then we
can actually gain some significant improvements:

array_map(sum2, $input1, $input2);

Currently that requires `sum2` to be a constant. To get the correct
behavior we currently need to do:

array_map('fully\qualified\namespace\sum2', $input1, $input2);

This is not just convenience; it provides safety to refactoring and
general code analysis tools. Maintenance is a crucial aspect of large
code bases and being able to move away from stringly-typed things is a
significant improvement. It's also a step towards general autoloading
instead of just class/trait/interface autoloading; however this would
require further changes.

I believe these improvements would be worth it and do understand it is
a large backwards compatibility break. Given sufficient time and
tooling to prepare I think PHP would be markedly better in the
long-run for these two changes. However, if we change only the case
sensitivity of constants we gain little value for our BC break.

Levi Morrison

8 years ago

> By itself this change provides little value. If it was done in
> connection with other features such as merging symbol tables then we
> can actually gain some significant improvements:
>
>     array_map(sum2, $input1, $input2);
>
> Currently that requires `sum2` to be a constant. To get the correct
> behavior we currently need to do:
>
>     array_map('fully\qualified\namespace\sum2', $input1, $input2);

After rewriting my reply I noticed this sentence doesn't quite make sense:

> This is not just convenience; it provides safety to refactoring and
> general code analysis tools.

Instead I meant that using the string is not just inconvenient; it
also prevents fully-safe code refactoring and analysis.

Rowan Collins

8 years ago

On 12 September 2017 15:52:38 BST, Levi Morrison <levim@php.net> wrote:

>    array_map(sum2, $input1, $input2);
>
>Currently that requires `sum2` to be a constant.

I'm not clear what this has to do with case sensitivity; the problem here is that we don't have a type of "function reference" (nor "class reference") so simulate such references with strings and runtime assertions.

Are you saying that without case sensitivity, the language could deduce that sum2 in that case was a function reference? That seems optimistic: not only can you have a class, a constant, and a function all with the same name, but you can't actually know which exists until the line is executed, because all three can be defined at any time.

This kind of ambiguous syntax is precisely what I was trying to reduce by deprecating "undefined constant as string", and a similar "convenient fallback" (from current to global namespace) is currently the biggest thing blocking function autoloading.

If we want function and class references, they should have their own, unambiguous, syntax.

Apologies if I've completely missed the point here.

Regards,

--
Rowan Collins
[IMSoP]

Levi Morrison

8 years ago

> Apologies if I've completely missed the point here.

Oh well, it happens.

> Are you saying that without case sensitivity, the language could deduce that sum2 in that case was a function reference? That seems optimistic: not only can you have a class, a constant, and a function all with the same name, but you can't actually know which exists until the line is executed, because all three can be defined at any time.

Close. If we make case sensitivity consistent (either all insensitive
or all sensitive) *and* merge symbol tables then we can get actual
features out of it. As it stands just changing the case sensitivity
does not buy as any features for our BC break.

The rest of my message only makes sense once you understand I was
proposing unified case sensitivity for all symbols *and* merging them
into one table.

>>    array_map(sum2, $input1, $input2);
>>
>>Currently that requires `sum2` to be a constant.
>
> I'm not clear what this has to do with case sensitivity; the problem here is that we don't have a type of "function reference" (nor "class reference") so simulate such references with strings and runtime assertions.

This confusion stems from the aforementioned items.

> If we want function and class references, they should have their own, unambiguous, syntax.

My point was rather that if we fix our inconsistency issues and merge
the tables no such syntax is required; all existing syntax works.
There are engine changes that have to accompany those as well,
obviously.

In summary I think changing constant case sensitivity is too small of
a step to gain us anything, but would be *very* happy to take it
further because it will give us actual features for our trouble.

Rowan Collins

8 years ago

On 12 September 2017 17:45:46 BST, Levi Morrison <levim@php.net> wrote:

>The rest of my message only makes sense once you understand I was
>proposing unified case sensitivity for all symbols *and* merging them
>into one table.

Ah, OK, so I partially missed the point. I'm still not sure what you're suggesting is sensible, though...

>> If we want function and class references, they should have their own,
>>unambiguous, syntax.

I stand by this assertion. Consider the following statement:

$foo = bar;

Even if "bar" cannot *simultaneously* be the name of a function, a class, and a constant, it can still *potentially* be any of the three, from the point of view of the compiler.

So, far from allowing us to make nice inferences about function references vs strings-that-look-callable, we have now *broken* assumptions we could previously have made.

It seems like we'd just be adding another equally ambiguous way of writing the same code.

Regards,

--
Rowan Collins
[IMSoP]

Levi Morrison

8 years ago

On Tue, Sep 12, 2017 at 11:59 AM, Rowan Collins <rowan.collins@gmail.com> wrote:

> On 12 September 2017 17:45:46 BST, Levi Morrison <levim@php.net> wrote:
>>The rest of my message only makes sense once you understand I was
>>proposing unified case sensitivity for all symbols *and* merging them
>>into one table.
>
> Ah, OK, so I partially missed the point. I'm still not sure what you're suggesting is sensible, though...
>
>
>>> If we want function and class references, they should have their own,
>>>unambiguous, syntax.
>
> I stand by this assertion. Consider the following statement:
>
> $foo = bar;
>
> Even if "bar" cannot *simultaneously* be the name of a function, a class, and a constant, it can still *potentially* be any of the three, from the point of view of the compiler.

If it's known, it's known, and it can proceed with that type. If it's
not known then autoload and proceed like normal. I fail to see how
this is an issue, and in fact, see it as a *significant* improvement
to our current situation...

Rowan Collins

8 years ago

Regards,
On 12 September 2017 21:35:51 BST, Levi Morrison <levim@php.net> wrote:

>On Tue, Sep 12, 2017 at 11:59 AM, Rowan Collins
><rowan.collins@gmail.com> wrote:
>>>> If we want function and class references, they should have their
>own,
>>>>unambiguous, syntax.
>>
>> I stand by this assertion. Consider the following statement:
>>
>> $foo = bar;
>>
>> Even if "bar" cannot *simultaneously* be the name of a function, a
>class, and a constant, it can still *potentially* be any of the three,
>from the point of view of the compiler.
>
>If it's known, it's known, and it can proceed with that type. If it's
>not known then autoload and proceed like normal. I fail to see how
>this is an issue, and in fact, see it as a *significant* improvement
>to our current situation...

If the symbol tables had always been unified, I guess you could think of a function name as a constant whose value happened to be of type IS_FUNC - like how in JS "function foo() {}" and "var foo = function{}" are very nearly interchangeable. But it feels like retrofitting that onto the existing language would be messy.

For instance, an autoloader would have to be given a token name, with no context of whether it's expected to be a class, function, or constant. (Of course we'd have to solve the dilemma of how global function fallback/shadowing should interact with autoloading first.) Users would have to learn this concept of an untyped token, because the error message they'd get if it wasn't defined could no longer say "undefined constant".

Then there's all the existing support for string-based callables. I can't actually think of any cases that are unresolvable, but there's some odd implications:

function foo() { echo 'Hello, world!'; }
const bar='foo';
$fn = bar;
$fn(); // already works
bar(); // would this work? if not, why not, since it's no longer ambiguous?
const baz='bar';
$fn2 = baz;
$fn2(); // in which case, would this also work?
baz(); // and then what about this?

I feel like this could lead to confusion either way, and just increase the complexity for both human and machine analysis.

Then there's other symbol tables that would need to be unified - we'd want $foo->bar be able to grant a method reference, and Foo::bar a static method reference. Just how much code is it worth breaking to allow this syntax?

It feels a lot cleaner to say "function and class references are a new concept, and you'll know when you're using them because they look like this". Something like "SomeClass::classref", "some_func::funcref", "SomeClass::someStaticMethod::funcref", "$some_object->someMethod::funcref".
 

--
Rowan Collins
[IMSoP]

Christoph Becker

8 years ago

On 12.09.2017 at 16:52, Levi Morrison wrote:

> On Tue, Sep 12, 2017 at 6:52 AM, François Laupretre
> <francois@tekwire.net> wrote:
>>
>> Le 12/09/2017 à 14:02, Christoph M. Becker a écrit :
>>
>>> 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.
>
> […] However, if we change only the case
> sensitivity of constants we gain little value for our BC break.

I have not suggested to *change* the case sensivity of constants, but
rather to settle on a common case – since `const` constants are always
case-sensitive, it appears that this should be so for define'd
constants.  This would make code as the following to work as expected:

a.php
<?php
const FOO = 'bar';
?>

b.php
<?php
define('FOO', 'baz', 1); // => true
echo FOO; // => bar - WFT?
?>

And it obviously would fix a bug.  IMHO, that is sufficient gain for a
presumably moderate BC break.

Please note, that I do not want to pursue a discussion regarding
changing all constants to be case-sensitive or all functions and class
names to be case-insensitive.  Of course, it is fine to discuss it, but
it is clearly out of scope for what I'm trying to improve (in my
opinion) here, which is more in the "a bird in the hand is worth two in
the bush" corner.

If it will be decided that all constant identifiers should be
case-insensitive, I'd be fine with it (not happy, though).  Probably, I
should reword the RFC to reflect that it is actually about deprecation
and removal of the third parameter of define() (plus preventing any
extension to register constants which do not conform to the "default"
casing).  In short: don't have two kinds of constants wrt. spelling
(true, false, null are not covered, since they are special anyway and
could be promoted to keywords).

--
Christoph M. Becker

--
Christoph

Niklas Keller

8 years ago

2017-09-12 14:02 GMT+02:00 Christoph M. Becker <cmbecker69@gmx.de>:

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

+1

Sara Golemon

8 years ago

On Tue, Sep 12, 2017 at 5:02 AM, Christoph M. Becker <cmbecker69@gmx.de> wrote:

> Even if these issues could be resolved, I still think allowing both
> case-sensitive and case-insensitive constant identifiers does more harm
> than good.
>

+0.1 to removing case-insensitive constants, though we'd need to
define both "null" and "NULL" (similar for true and false) since
there's little consensus on which version of these constants get used
from project to project.  Also: While deprecating for 7.3 is fine, I'd
favor waiting for 8.0 for full removal.

As to François' suggestion to make the whole language case-sensitive?
Yeesh, that feels like a much more aggressive movement.  In the case
of constants they very nearly are case-sensitive only since, as you
point out, common practice is to not pass true for that third
parameter, and to prefer `const` over `define` anyway.  Identifiers
are another matter since they're insensitive by default.

In the case of classnames I could almost get on board since
autoloading standards have pushed users naturally in the direction of
respecting case sensitive as a coding standard.  I don't feel as
though that's true of functions or of projects where autoloaders
aren't used (not a small number).

Overall: No.  I'm -1 on making non-constant identifiers
case-sensitive.  At best, I'd perhaps get on board with a
declare(case_sensitivity=1); style directive.

-Sara

Tony Marston

8 years ago

"Sara Golemon"  wrote in message
news:CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=U_F3gd87rmxrQ@mail.gmail.com...

>
>On Tue, Sep 12, 2017 at 5:02 AM, Christoph M. Becker <cmbecker69@gmx.de>
>wrote:
>> Even if these issues could be resolved, I still think allowing both
>> case-sensitive and case-insensitive constant identifiers does more harm
>> than good.
>>
>+0.1 to removing case-insensitive constants, though we'd need to
>define both "null" and "NULL" (similar for true and false) since
>there's little consensus on which version of these constants get used
>from project to project.  Also: While deprecating for 7.3 is fine, I'd
>favor waiting for 8.0 for full removal.
>
>As to François' suggestion to make the whole language case-sensitive?
>Yeesh, that feels like a much more aggressive movement.  In the case
>of constants they very nearly are case-sensitive only since, as you
>point out, common practice is to not pass true for that third
>parameter, and to prefer `const` over `define` anyway.  Identifiers
>are another matter since they're insensitive by default.
>
>In the case of classnames I could almost get on board since
>autoloading standards have pushed users naturally in the direction of
>respecting case sensitive as a coding standard.  I don't feel as
>though that's true of functions or of projects where autoloaders
>aren't used (not a small number).

You seem to forget that autoloading is an option, not a requirement. I don't
use autoloading in my 14 year old framework for several reasons:
- An autoloader did not exist when I created my framework.
- I built an alternative mechanism into my framework, so I don't need an
autoloader.
- I don't like the way autoloaders work - all my class names are in snake
case (lowercase with underscore separators) and the autoloader converts '_'
into '/' thus producing a file path which does not exist.

By convention I always use uppercase for constants which makes them
instantly recognisable in my code as all other names are either completely
lowercase or mixed case. Making constants case sensitive instead of
insensitive would not affect me.

However, I would be totally against switching the rest of the language to be
case sensitive for the following reasons:
- It would be a huge BC break no little or no benefit.
- It would allow developers to shoot themselves in the foot by having
different functions with the same name but different mixtures of case, so
that foo(), Foo() FOO() and fOO() would be treated as different functions.
- if people move from keyboard input to speech recognition, then simply
speaking a name would not work - you would have to spell it out character by
character, and specify either upper or lowercase for each character.

People who think that case sensitive software is cool are deluding
themselves. When I started working on mainframe computers (UNIVAC and IBM)
in the early 1970s everything was case-insensitive. This was only changed by
people who did not understand the ramifications of their choice.

--
Tony Marston

Ryan Pallas

8 years ago

On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston <TonyMarston@hotmail.com>
wrote:

>
>>
> You seem to forget that autoloading is an option, not a requirement. I
> don't use autoloading in my 14 year old framework for several reasons:
> - An autoloader did not exist when I created my framework.
> - I built an alternative mechanism into my framework, so I don't need an
> autoloader.
> - I don't like the way autoloaders work - all my class names are in snake
> case (lowercase with underscore separators) and the autoloader converts '_'
> into '/' thus producing a file path which does not exist.
>

I must be missing something, there is no autoloader shipped with PHP. You
have to define your own and register it. You can choose to change _ into /
within your autoloader, but that is entirely preference and not
specifically part of autoloading. For example, here's my autoloader which
does no such symbol replacement https://pastebin.com/rQRrXzCa

>
> By convention I always use uppercase for constants which makes them
> instantly recognisable in my code as all other names are either completely
> lowercase or mixed case. Making constants case sensitive instead of
> insensitive would not affect me.
>
> However, I would be totally against switching the rest of the language to
> be case sensitive for the following reasons:
> - It would be a huge BC break no little or no benefit.
> - It would allow developers to shoot themselves in the foot by having
> different functions with the same name but different mixtures of case, so
> that foo(), Foo() FOO() and fOO() would be treated as different functions.
> - if people move from keyboard input to speech recognition, then simply
> speaking a name would not work - you would have to spell it out character
> by character, and specify either upper or lowercase for each character.
>

This is about deprecating the third parameter in define, so userland
constants defined by this function cannot be case insensitive. As mentioned
before by Christoph this is not an attempt to change case sensitivity for
other identifiers (functions, classes, etc) even if it was brought up
before. That is not his intention here, and we need to stick to the focus
of this RFC.

Rowan Collins

8 years ago

On 13 September 2017 14:15:43 BST, Ryan Pallas <derokorian@gmail.com> wrote:

>I must be missing something, there is no autoloader shipped with PHP.

Just to be pedantically correct, there actually is an implementation shipped, see http://php.net/spl_autoload It's even the default if you don't pass your own function to spl_autoload_register.

Nonetheless, you are quite right that Tony's complaint is nonsensical, because he could implement whatever autoloader suited his directory structure, if he wanted to - even a case insensitive one.

It is true that autoloading isn't mandatory, but it's also a complete straw man, because Sara already made the same point herself:

> I don't feel as though that's true of ...
> projects where autoloaders
> aren't used (not a small number).

Regards,

--
Rowan Collins
[IMSoP]

Ryan Pallas

8 years ago

On Wed, Sep 13, 2017 at 8:06 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 13 September 2017 14:15:43 BST, Ryan Pallas <derokorian@gmail.com>
> wrote:
> >I must be missing something, there is no autoloader shipped with PHP.
>
> Just to be pedantically correct, there actually is an implementation
> shipped, see http://php.net/spl_autoload It's even the default if you
> don't pass your own function to spl_autoload_register.
>

Almost 2 decades in PHP, and still so much I don't know haha. I will point
out though, that according to a comment [1] it does not replace the
underscores with slashes as mentioned, and I see no where in the code [2]
that it does either.

[1] http://php.net/manual/en/function.spl-autoload.php#98762
[2] https://github.com/php/php-src/blob/master/ext/spl/php_spl.c#L306

Tony Marston

8 years ago

"Ryan Pallas"  wrote in message
news:CAObuZdtmhxQ285hwMc3x9TH2rj9D7Ty3vnhNPcBzdCePpch9YA@mail.gmail.com...

>
>On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston <TonyMarston@hotmail.com>
>wrote:
>
>>
>>>
>> You seem to forget that autoloading is an option, not a requirement. I
>> don't use autoloading in my 14 year old framework for several reasons:
>> - An autoloader did not exist when I created my framework.
>> - I built an alternative mechanism into my framework, so I don't need an
>> autoloader.
>> - I don't like the way autoloaders work - all my class names are in snake
>> case (lowercase with underscore separators) and the autoloader converts
>> '_'
>> into '/' thus producing a file path which does not exist.
>>
>
>I must be missing something, there is no autoloader shipped with PHP. You
>have to define your own and register it. You can choose to change _ into /
>within your autoloader, but that is entirely preference and not
>specifically part of autoloading. For example, here's my autoloader which
>does no such symbol replacement https://pastebin.com/rQRrXzCa
>
>

Then it must have been the project I was working on which used a combination
of Codeigniter, Composer and PHPUnit. There was definitely something which
translated a class name from "foo_bar_snafu" into "foo/bar/snafu". It's no
wonder that I stopped using it.

--
Tony Marston

http://www.tonymarston.net
http://www.radicore.org

Lester Caine

8 years ago

On 13/09/17 09:59, Tony Marston wrote:

> People who think that case sensitive software is cool are deluding
> themselves. When I started working on mainframe computers (UNIVAC and
> IBM) in the early 1970s everything was case-insensitive.

Life was so much easier when using an RTTY as the keyboard and printer.
No one had invented the shift key and the 5 bit character set was easy
to work with.

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

Levi Morrison

8 years ago

On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston <TonyMarston@hotmail.com> wrote:

> People who think that case sensitive software is cool are deluding
> themselves. When I started working on mainframe computers (UNIVAC and IBM)
> in the early 1970s everything was case-insensitive. This was only changed by
> people who did not understand the ramifications of their choice.

Actually there are concrete bugs caused by case insensitivity. For one
example, here is our own bugs.php.net report about a Turkish locale
issue:

https://bugs.php.net/bug.php?id=18556

The short summary of the issue is that when capital `I`, the ninth
letter of the English alphabet, is lowercased in the Turkish locales
it does not become the same `i` as it does in English but a different
i that is not considered equal. Thus classes such as `Iterator` are
not found in the Turkish locales. Note that this bug was fixed, and
then there was a regression that lasted until PHP 5.5.

There are other case insensitivity bugs but this Turkish one is the
poster child and if you search around you can find many examples of
it.

Case sensitivity is thus *a correctness issue* and not a "cool"ness,
personal preference, performance, or some other type of issue. I argue
correctness and maintenance issues are the most important and thus if
we change sensitivity of *any* type of symbol it should go in the
direction of being case sensitive. Someone can disagree on what they
value but people who think case insensitivity is not a correctness
issue "are deluding themselves".

Levi Morrison

Tony Marston

8 years ago

"Levi Morrison"  wrote in message
news:CAFMT4NrC43y-nL_V85qt7JgV1ohM0y4KExhB4e3mi1EjHJ0hBw@mail.gmail.com...

>
>On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston <TonyMarston@hotmail.com>
>wrote:
>> People who think that case sensitive software is cool are deluding
>> themselves. When I started working on mainframe computers (UNIVAC and
>> IBM)
>> in the early 1970s everything was case-insensitive. This was only changed
>> by
>> people who did not understand the ramifications of their choice.
>
>Actually there are concrete bugs caused by case insensitivity. For one
>example, here is our own bugs.ph p.net report about a Turkish locale
>issue:
>
>    https://bugs.php.net/bug.php?id=18556
>
>The short summary of the issue is that when capital `I`, the ninth
>letter of the English alphabet, is lowercased in the Turkish locales
>it does not become the same `i` as it does in English but a different
>i that is not considered equal. Thus classes such as `Iterator` are
>not found in the Turkish locales. Note that this bug was fixed, and
>then there was a regression that lasted until PHP 5.5.
>
>There are other case insensitivity bugs but this Turkish one is the
>poster child and if you search around you can find many examples of
>it.
>
>Case sensitivity is thus *a correctness issue* and not a "cool"ness,
>personal preference, performance, or some other type of issue. I argue
>correctness and maintenance issues are the most important and thus if
>we change sensitivity of *any* type of symbol it should go in the
>direction of being case sensitive. Someone can disagree on what they
>value but people who think case insensitivity is not a correctness
>issue "are deluding themselves".
>
>Levi Morrison

I'm sorry, but errors in translation from one character set to another are
insignificant when compared with the much larger problem of the same word
having diferent meanings depending on case. In the English language "info"
is the same as "Info" is the same as "INFO" is the same as "iNFO" is the
same as "iNfO" and so on. If the problem is that an English word cannot be
recognised as the same word regardless of case when switching to a
non-English character set then the issue is with switching to a non-English
character set.

Introducing case sensitivity just for this minor bug would create more
issues than it would solve, so this bug should be solved using a different
technique .

--
Tony Marston

Tony Marston

8 years ago

""Tony Marston""  wrote in message news:09.43.19300.8E659B95@pb1.pair.com...

>
>"Levi Morrison"  wrote in message
>news:CAFMT4NrC43y-nL_V85qt7JgV1ohM0y4KExhB4e3mi1EjHJ0hBw@mail.gmail.com...
>>
>>On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston <TonyMarston@hotmail.com>
>>wrote:
>>> People who think that case sensitive software is cool are deluding
>>> themselves. When I started working on mainframe computers (UNIVAC and
>>> IBM)
>>> in the early 1970s everything was case-insensitive. This was only
>>> changed by
>>> people who did not understand the ramifications of their choice.
>>
>>Actually there are concrete bugs caused by case insensitivity. For one
>>example, here is our own bugs.ph p.net report about a Turkish locale
>>issue:
>>
>>    https://bugs.php.net/bug.php?id=18556
>>
>>The short summary of the issue is that when capital `I`, the ninth
>>letter of the English alphabet, is lowercased in the Turkish locales
>>it does not become the same `i` as it does in English but a different
>>i that is not considered equal. Thus classes such as `Iterator` are
>>not found in the Turkish locales. Note that this bug was fixed, and
>>then there was a regression that lasted until PHP 5.5.
>>
>>There are other case insensitivity bugs but this Turkish one is the
>>poster child and if you search around you can find many examples of
>>it.
>>
>>Case sensitivity is thus *a correctness issue* and not a "cool"ness,
>>personal preference, performance, or some other type of issue. I argue
>>correctness and maintenance issues are the most important and thus if
>>we change sensitivity of *any* type of symbol it should go in the
>>direction of being case sensitive. Someone can disagree on what they
>>value but people who think case insensitivity is not a correctness
>>issue "are deluding themselves".
>>
>>Levi Morrison
>
>I'm sorry, but errors in translation from one character set to another are
>insignificant when compared with the much larger problem of the same word
>having diferent meanings depending on case. In the English language "info"
>is the same as "Info" is the same as "INFO" is the same as "iNFO" is the
>same as "iNfO" and so on. If the problem is that an English word cannot be
>recognised as the same word regardless of case when switching to a
>non-English character set then the issue is with switching to a non-English
>character set.
>
>Introducing case sensitivity just for this minor bug would create more
>issues than it would solve, so this bug should be solved using a different
>technique .
>

Would this problem disappear by using UTF8 instead of the Turkish character
set? If so then ten no other solution would be required.

--
Tony Marston

Rowan Collins

8 years ago

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.

Early programming languages and OSes just ignored the edge cases (or ignored the existence of the world outside the USA altogether), some later ones decided the whole thing wasn't worth the effort.

Regards,

--
Rowan Collins
[IMSoP]

Tony Marston

8 years ago

"Rowan Collins"  wrote in message
news:A7FFCE81-74E5-47D0-9EBF-9BDC90E2E957@gmail.com...

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

Sara Golemon

8 years ago

On Wed, Sep 13, 2017 at 8:59 AM, Tony Marston <TonyMarston@hotmail.com> wrote:

> "Sara Golemon"  wrote in message
> news:CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=U_F3gd87rmxrQ@mail.gmail.com...
>> +0.1 to removing case-insensitive constants, though we'd need to
>> define both "null" and "NULL" (similar for true and false) since
>> there's little consensus on which version of these constants get used
>> from project to project.  Also: While deprecating for 7.3 is fine, I'd
>> favor waiting for 8.0 for full removal.
>>
>> As to François' suggestion to make the whole language case-sensitive?
>> Yeesh, that feels like a much more aggressive movement.  In the case
>> of constants they very nearly are case-sensitive only since, as you
>> point out, common practice is to not pass true for that third
>> parameter, and to prefer `const` over `define` anyway.  Identifiers
>> are another matter since they're insensitive by default.
>>
>> In the case of classnames I could almost get on board since
>> autoloading standards have pushed users naturally in the direction of
>> respecting case sensitive as a coding standard.  I don't feel as
>> though that's true of functions or of projects where autoloaders
>> aren't used (not a small number).
>
>
> You seem to forget that autoloading is an option, not a requirement.
>

I don't forget any such thing.  I noted it as a phenomenon which has
*pushed* users in a particular direction, but by no means have all
users gone that way, as you note about yourself. Indeed, I have a 10
year old framework still in use at a previous company which does many
similar things for many similar reasons.

I also stated that I could *almost* get on board.  Almost is not 100%,
it's arguably not even 50% since it implies not actually crossing some
minimum required threshold.

> - I don't like the way autoloaders work - all my class names are in snake
> case (lowercase with underscore separators) and the autoloader converts '_'
> into '/' thus producing a file path which does not exist.
>

Nit; That's autoloader specific.  PSR-0 defines that behavior, but
PSR-4 does not, for example.

> By convention I always use uppercase for constants which makes them
> instantly recognisable in my code as all other names are either completely
> lowercase or mixed case. Making constants case sensitive instead of
> insensitive would not affect me.
>

Agreed, nor I suspect would it effect most other users regardless of
which case they use since the trend is to not use case-insensitive
constants in the first place.

> People who think that case sensitive software is cool are deluding
> themselves. When I started working on mainframe computers (UNIVAC and IBM)
> in the early 1970s everything was case-insensitive. This was only changed by
> people who did not understand the ramifications of their choice.
>

Yeah, decades of C/C++/Java developers are so dumb, like... fer reals.
Friggin' script kiddies, the lot of 'em.

-Sara

Tony Marston

8 years ago

"Sara Golemon"  wrote in message
news:CAESVnVp6OKB64WuO9iKEP=L9-QrrFjS+kcoeKYKULRUff-RitQ@mail.gmail.com...

>
>On Wed, Sep 13, 2017 at 8:59 AM, Tony Marston <TonyMarston@hotmail.com>
>wrote:

<snip>

>> People who think that case sensitive software is cool are deluding
>> themselves. When I started working on mainframe computers (UNIVAC and
>> IBM)
>> in the early 1970s everything was case-insensitive. This was only changed
>> by
>> people who did not understand the ramifications of their choice.
>>
>Yeah, decades of C/C++/Java developers are so dumb, like... fer reals.
>Friggin' script kiddies, the lot of 'em.
>
>-Sara

If the first programming languages in the first computers were case
insensitive, then that should be the standard. Those who introduced case
sensitive languages at a later date should be forced to justify that
decision. It is the same for file systems - all the pre-unix systems I
worked on were case insensitive, as have been all versions of Microsoft
Windows. Then unix came along and FUBAR'd everything. Any advantages of case
sensitive systems are ALWAYS outweighed by their disadvantages.

A similar cockup occurred with line endings. The original convention on
teletypes was to use line-feed (LF) and carriage-return (CR) together which
have separate meanings and could either be used independently or together.
Then some clueless newbies came along and changed everything so that some
OSes use just LF while others use just just CR. This now causes problems
when transferring files from one OS to another. This shows what happens when
"friggin' script kiddies" (your words, not mine) come up with an idea
without understanding what the current convention is.

--
Tony Marston

Daniel Morris

8 years ago

On Thu, 14 Sep 2017, at 10:20 AM, Tony Marston wrote:

> If the first programming languages in the first computers were case
> insensitive, then that should be the standard. Those who introduced case
> sensitive languages at a later date should be forced to justify that
> decision.

If the first vehicles had two wheels, then that should be the standard.
Those who introduced cars with four wheels should be forced to justify
that decision.

If the first television was black and white, then that should be the
standard. Those who introduced televisions with colour should be forced
to justify that decision.

If the first living organisms had single cells, then that should be the
standard. Evolution should be forced to justify the decision to move to
multiple cells.

If light exists as a wave, then that should be the standard. When an
observer collapses the wave function, then they should be forced to
justify that decision.

--
Daniel Morris
daniel@honestempire.com

Tony Marston

8 years ago

"Daniel Morris"  wrote in message
news:1505382004.4078127.1105791680.3A06C2FA@webmail.messagingengine.com...

>
>On Thu, 14 Sep 2017, at 10:20 AM, Tony Marston wrote:
>> If the first programming languages in the first computers were case
>> insensitive, then that should be the standard. Those who introduced case
>> sensitive languages at a later date should be forced to justify that
>> decision.
>
>If the first vehicles had two wheels, then that should be the standard.
>Those who introduced cars with four wheels should be forced to justify
>that decision.
>
>If the first television was black and white, then that should be the
>standard. Those who introduced televisions with colour should be forced
>to justify that decision.
>
>If the first living organisms had single cells, then that should be the
>standard. Evolution should be forced to justify the decision to move to
>multiple cells.
>
>If light exists as a wave, then that should be the standard. When an
>observer collapses the wave function, then they should be forced to
>justify that decision.
>
>--
>Daniel Morris
>daniel@honestempire.com

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

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

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

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

--
Tony Marston

Christoph Becker

8 years ago

On 14.09.2017 at 14:59, Tony Marston wrote:

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

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

--
Christoph M. Becker

Tony Marston

8 years ago

""Christoph M. Becker""  wrote in message
news:98ab178e-b999-7e36-5ff5-7b8c28fe0dd4@gmx.de...

>
>On 14.09.2017 at 14:59, Tony Marston wrote:
>
>> Introducing case sensitivity into what is mostly a case-insensitive
>> world just for the convenience of a few programmers I do not consider to
>> be acceptable. It would cause more problems for far more people than the
>> insignificant few who insist on using obscure character sets. Why should
>> the English-speaking world be forced to suffer just because some minor
>> languages cannot handle case folding?
>
>This is not about an "insignificant few who insist on using obscure
>character sets", but rather about a language spoken by millions of
>people which has to "I" characters, namely dotted and dotless "I".
>Rather consistently, the dotless "I"'s lower-case variant is "i", and
>the dotted "I"'s lower-case variant is "i".  There you go.
>

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

--
Tony Marston

Alain Williams

8 years ago

On Thu, Sep 14, 2017 at 02:36:27PM +0100, Tony Marston wrote:

> ""Christoph M. Becker""  wrote in message
> news:98ab178e-b999-7e36-5ff5-7b8c28fe0dd4@gmx.de...
> >
> >On 14.09.2017 at 14:59, Tony Marston wrote:
> >
> >>Introducing case sensitivity into what is mostly a case-insensitive
> >>world just for the convenience of a few programmers I do not consider to
> >>be acceptable. It would cause more problems for far more people than the
> >>insignificant few who insist on using obscure character sets. Why should
> >>the English-speaking world be forced to suffer just because some minor
> >>languages cannot handle case folding?
> >
> >This is not about an "insignificant few who insist on using obscure
> >character sets", but rather about a language spoken by millions of
> >people which has to "I" characters, namely dotted and dotless "I".
> >Rather consistently, the dotless "I"'s lower-case variant is "i", and
> >the dotted "I"'s lower-case variant is "i".  There you go.
> >
>
> The number of people in the world who use character sets which do
> not have this problem far outnumber those who use character sets
> which do have this problem. People without this problem far
> outnumber the others, so it would not be a good idea to
> inconvenience the many just to satisfy the few.

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

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

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

Rowan Collins

8 years ago

On 14 September 2017 13:59:20 BST, Tony Marston <TonyMarston@hotmail.com> wrote:

> Why should the
>English-speaking world be forced to suffer just because some minor
>languages
>cannot handle case folding?

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

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

Regards,

--
Rowan Collins
[IMSoP]

Tony Marston

8 years ago

"Rowan Collins"  wrote in message
news:7394E3CE-B05A-474E-8AB5-A651FDD35232@gmail.com...

>
>On 14 September 2017 13:59:20 BST, Tony Marston <TonyMarston@hotmail.com>
>wrote:
>> Why should the
>>English-speaking world be forced to suffer just because some minor
>>languages
>>cannot handle case folding?
>
>Have you any idea how arrogant this sounds? Why should "the
>English-speaking world" get to make up the rules? What criteria make
>something "a minor language"? Who gave you the right to make such lofty
>pronouncements?

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

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

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

--
Tony Marston

Alain Williams

8 years ago

On Thu, Sep 14, 2017 at 02:48:06PM +0100, Tony Marston wrote:

> "Rowan Collins"  wrote in message
> news:7394E3CE-B05A-474E-8AB5-A651FDD35232@gmail.com...
> >
> >On 14 September 2017 13:59:20 BST, Tony Marston
> ><TonyMarston@hotmail.com> wrote:
> >>Why should the
> >>English-speaking world be forced to suffer just because some minor
> >>languages
> >>cannot handle case folding?
> >
> >Have you any idea how arrogant this sounds? Why should "the
> >English-speaking world" get to make up the rules? What criteria
> >make something "a minor language"? Who gave you the right to make
> >such lofty pronouncements?
>
> Because the English-speaking world invented both computers and the
> languages used to program them.

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

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

Daniel Morris

8 years ago

On Thu, 14 Sep 2017, at 02:48 PM, Tony Marston wrote:

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

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

On Thu, 14 Sep 2017, at 02:36 PM, Tony Marston wrote:

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

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

--
Daniel Morris
daniel@honestempire.com

Lester Caine

8 years ago

On 14/09/17 10:20, Tony Marston wrote:

> Then unix came along and FUBAR'd everything. Any advantages of case
> sensitive systems are ALWAYS outweighed by their disadvantages.

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

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

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Michael Morris

8 years ago

On Thu, Sep 14, 2017 at 8:33 AM, Lester Caine <lester@lsces.co.uk> wrote:

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

*Cough*, *Cough*, PHP 6, *Cough*, *Cough*.

Comedy aside, Full UTF functionality was planned for PHP 6 and ended up
sinking the branch because it was way more complicated that anyone realized
at first. Someone involved with the development at that time can speak to
it more accurately - all I know is hearsay and conjecture.

Lester Caine

8 years ago

On 14/09/17 14:10, Michael Morris wrote:

> On Thu, Sep 14, 2017 at 8:33 AM, Lester Caine <lester@lsces.co.uk> wrote:
>
>> UTF8 introduces a level of complexity and can be used used in many
>> places in PHP, but it does seem that there is no drive these days to
>> make the core a clean UTF8 environment. This should perhaps be addressed
>> again for PHP8?
>>
> *Cough*, *Cough*, PHP 6, *Cough*, *Cough*.
>
> Comedy aside, Full UTF functionality was planned for PHP 6 and ended up
> sinking the branch because it was way more complicated that anyone realized
> at first. Someone involved with the development at that time can speak to
> it more accurately - all I know is hearsay and conjecture.

My point exactly ...

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Tony Marston

8 years ago

"Lester Caine"  wrote in message
news:20b8b6fa-ec81-eba9-d33b-b54b815e9e5d@lsces.co.uk...

>
>On 14/09/17 10:20, Tony Marston wrote:
>> Then unix came along and FUBAR'd everything. Any advantages of case
>> sensitive systems are ALWAYS outweighed by their disadvantages.
>
>Unix predates Windows ...

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

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

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

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

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

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

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

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

--
Tony Marston

Alain Williams

8 years ago

On Thu, Sep 14, 2017 at 02:16:47PM +0100, Tony Marston wrote:

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

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

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

This is what Javascript does.

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

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

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

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

François Laupretre

8 years ago

Le 14/09/2017 à 15:38, Alain Williams a écrit :

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

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

Regards

François

Sara Golemon

8 years ago

On Thu, Sep 14, 2017 at 11:37 AM, François Laupretre
<francois@tekwire.net> wrote:

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

+0.9 this.  It feels pretty simple to resolve this special-case for
case-sensitivity at any stage of the compile, but the reality is that
TRUE/True/true covers 99% of uses, and a static analyzer can
*trivially* find those other cases prior to an upgrade.  Heck, 3
minutes with a token_get_all() script can find 'em, even produce a
rewrite diff if you're so inclined.

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

-Sara

Christoph Becker

8 years ago

On 14.09.2017 at 17:37, François Laupretre wrote:

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

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

--
Christoph M. Becker

Tony Marston

8 years ago

"Alain Williams"  wrote in message
news:20170914133846.GQ8096@phcomp.co.uk...

>
>On Thu, Sep 14, 2017 at 02:16:47PM +0100, Tony Marston wrote:
>
>> A minor detail. Windows followed all the previous OSes which I had
>> used in being case insensitive, which makes unix the odd one out.
>> Besides there are far more computers running Windows than unix, so
>> unixx should not be used as the standard.
>
>So you want a return to the horrors of code pages in file systems ?

I never said that.

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

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

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

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

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

I don't give two hoots what javascript does.

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

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

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

--
Tony Marston

Andrey Andreev

8 years ago

Hi,

On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston <TonyMarston@hotmail.com> wrote:

>
>> Far better that that
>> problem is taken away from the file system (which should be clean, robust
>> and
>> fast) and if you want case independence put it up at the application
>> layer.
>
>
> You try telling that to the billions of Windows users who have been used to
> a case insensitive file system for decades. Not to mention all Microsoft
> software which is case insensitive. Try to take that away and billions of
> users will be baying for your blood.
>

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

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

Cheers,
Andrey.

Alain Williams

8 years ago

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>

Stas Malyshev

8 years ago

Hi!

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

The latter case probably should be fixed by not allowing second constant
to be defined. If you already have case-insensitive constant, it should
cover all of those.

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

I don't think HHVM not supporting something can be an argument. I'm
worried about TRUE vs. True vs. true though - I've see all of those used
around the code (not tRuE though ;) and breaking that would add a ton of
meaningless work to maintainers without any upside. Same with NULL/null etc.

I am also not convinced those constants are really that bad. I'd
probably be fine with phasing out manual defines for case-insensitives
though. But I'm not sure what purpose it would serve then - the engine
would still have to support it, no?

--
Stas Malyshev
smalyshev@gmail.com

Sara Golemon

8 years ago

On Tue, Sep 12, 2017 at 7:43 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:

> I don't think HHVM not supporting something can be an argument.
>

I agree there, though I will offer that part of the reason HHVM has
never bothered to support case-insensitive constants is that it's
simply never needed to.  The only major project that didn't work out
of the box was Wordpress, and when they saw my blogpost about their
one case-insensitive constant, they switched it to being
case-sensitive, because EVEN WORDPRESS thought they'd maintained that
BC long enough. :)

> I'm worried about TRUE vs. True vs. true though - I've see all of those used
> around the code (not tRuE though ;) and breaking that would add a ton of
> meaningless work to maintainers without any upside. Same with NULL/null etc.
>

We could always special case these in the lexer, or during
compile-time constant folding.  I agree they're a concern (and already
noted as much in my previous reply), but they're an entirely tractable
concern.

-Sara

Christoph Becker

8 years ago

On 12.09.2017 at 21:55, Sara Golemon wrote:

> On Tue, Sep 12, 2017 at 7:43 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>
>> I'm worried about TRUE vs. True vs. true though - I've see all of those used
>> around the code (not tRuE though ;) and breaking that would add a ton of
>> meaningless work to maintainers without any upside. Same with NULL/null etc.
>
> We could always special case these in the lexer, or during
> compile-time constant folding.  I agree they're a concern (and already
> noted as much in my previous reply), but they're an entirely tractable
> concern.

Sorry, I forgot to mention these special constants which are reserved
words right now.  Of course, these have to stay case-insensitive, and we
simply could promote them to keywords which are case-insensitive, anyway.

--
Christoph M. Becker

Nikita Popov

8 years ago

On Tue, Sep 12, 2017 at 8:02 PM, Christoph M. Becker <cmbecker69@gmx.de>
wrote:

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

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

Nikita

Stas Malyshev

8 years ago

Hi!

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

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

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

--
Stas Malyshev
smalyshev@gmail.com

Christoph Becker

8 years ago

On 14.09.2017 at 23:22, Stanislav Malyshev wrote:

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

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

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

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

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

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

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

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

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

--
Christoph M. Becker

Stas Malyshev

8 years ago

Hi!

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

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

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

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

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

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

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

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

--
Stas Malyshev
smalyshev@gmail.com

Christoph Becker

8 years ago

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

Tony Marston

8 years ago

""Christoph M. Becker""  wrote in message
news:320b3863-e36b-2ed4-543b-fcbd433b1c56@gmx.de...

>
>On 14.09.2017 at 23:22, Stanislav Malyshev wrote:
>
>> [Nikita wrote]
>>
>>> +1 on doing this. I can understand having case-insensitive constants,
>>> but
>>> having both case-sensitive and case-insensitive at the same time is
>>> weird
>>> and rather useless. I imagine the only reason why this "feature" exists
>>> in
>>> the first place is to support arbitrary casing for true/false/null,
>>> which
>>> is better handled by special-casing these particular constants
>>> (something
>>> we already do for various other reasons). This will simplify the
>>> language
>>
>> If we support all case-insensitive constants that are predefined (not
>> sure if any exts do that but we have to support those too if they do)
>> then I don't see a big problem in phasing-out user-defined ones.
>
>It seems to me that this would miss the point, namely to introduce some
>consistency, and to be able to
>
>> [Nikita continued]
>>
>>> reduce implementation complexity on our side and resolve some bugs
>>> that are infeasible to fix otherwise.
>
>All programming languages that I know of are either case-sensitive or
>case-insensitive.

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

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

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

--
Tony Marston

lists@rhsoft.net

8 years ago

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

Tony Marston

8 years ago

wrote in message news:5fe274c1-36de-e650-fd2c-bc4f9caf36f3@rhsoft.net...

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

lists@rhsoft.net

8 years ago

Am 15.09.2017 um 16:58 schrieb Tony Marston:

> wrote in message news:5fe274c1-36de-e650-fd2c-bc4f9caf36f3@rhsoft.net...
>>
>> 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?

Tony Marston

8 years ago

wrote in message news:bd24d73e-4999-ffd9-ce03-6b76290372b1@rhsoft.net...

>
>
>
>Am 15.09.2017 um 16:58 schrieb Tony Marston:
>> wrote in message news:5fe274c1-36de-e650-fd2c-bc4f9caf36f3@rhsoft.net...
>>>
>>> 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

lists@rhsoft.net

8 years ago

Am 16.09.2017 um 11:36 schrieb Tony Marston:

> wrote in message news:bd24d73e-4999-ffd9-ce03-6b76290372b1@rhsoft.net...
>> 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

Sara Golemon

8 years ago

On Tue, Sep 12, 2017 at 8:02 AM, Christoph M. Becker <cmbecker69@gmx.de> wrote:

> Usually constant identifiers are treated case-sensitive in PHP.  This is
> always the case for constants defined via a `const` declaration.
> However, define() allows to pass TRUE as third argument to define a
> case-insensitive constant.  This feature appears to potentially result
> in confusion, and also causes bugs as shown in
> <https://bugs.php.net/74450>.  See an example created by Nikita to see
> some probably unexpected behavior: <https://3v4l.org/L6nCp>.
>

I'd just like to ask everyone on this thread to circle back to the
actual topic: Case-Insensitive Constants.  Nothing else is on topic
here.  If you'd like to argue the value of Turkish case folding and
its impact on combined symbol tables in 40 year old software, I
encourage you to start a new thread for that topic.

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

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

-Sara

Levi Morrison

8 years ago

On Thu, Sep 14, 2017 at 9:38 AM, Sara Golemon <pollita@php.net> wrote:

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

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

Sara Golemon

8 years ago

On Thu, Sep 14, 2017 at 12:02 PM, Levi Morrison <levim@php.net> wrote:

> On Thu, Sep 14, 2017 at 9:38 AM, Sara Golemon <pollita@php.net> wrote:
>> On Tue, Sep 12, 2017 at 8:02 AM, Christoph M. Becker <cmbecker69@gmx.de> wrote:
>>> Usually constant identifiers are treated case-sensitive in PHP.  This is
>>> always the case for constants defined via a `const` declaration.
>>> However, define() allows to pass TRUE as third argument to define a
>>> case-insensitive constant.  This feature appears to potentially result
>>> in confusion, and also causes bugs as shown in
>>> <https://bugs.php.net/74450>.  See an example created by Nikita to see
>>> some probably unexpected behavior: <https://3v4l.org/L6nCp>.
>>>
>> I'd just like to ask everyone on this thread to circle back to the
>> actual topic: Case-Insensitive Constants.  Nothing else is on topic
>> here.  If you'd like to argue the value of Turkish case folding and
>> its impact on combined symbol tables in 40 year old software, I
>> encourage you to start a new thread for that topic.
>>
>> Of the minority of responses to this thread reflecting on the actual
>> goal of the proposal, I've seen responses from "sure, why not?" to
>> "what's the point?", but if there was a coherent argument firmly
>> against, I must have missed it.
>>
>> So could we focus on the topic at hand, please?
>
> For what it is worth the Turkish locale issue is on-topic. If we have
> case sensitivity and case insensitivity simultaneously in constants
> and we decide to drop one then the locale issue points towards
> dropping case insensitivity.
>

Except that we don't actually support case-insensitive constants and
never have.  We support ASCII case-insensitivity.  Of course, this
supports your "let's drop case insensitivity" position on the grounds
that our implementation of it is ironically parochial and terrible.

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

https://3v4l.org/Od03d

-Sara

Zeev Suraski

8 years ago

> -----Original Message-----
> From: Christoph M. Becker [mailto:cmbecker69@gmx.de]
> 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

Levi Morrison

8 years ago

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

Zeev Suraski

8 years ago

> -----Original Message-----
> From: morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] On Behalf
> Of Levi Morrison
> Sent: Saturday, September 16, 2017 6:25 PM
> To: Zeev Suraski <zeev@zend.com>
> Cc: Christoph M. Becker <cmbecker69@gmx.de>; 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

8 years ago

On Sat, Sep 16, 2017 at 11:04 AM, Zeev Suraski <zeev@zend.com> 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

Stas Malyshev

8 years ago

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

Stas Malyshev

8 years ago

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

Christoph Becker

8 years ago

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