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

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 inhttps://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.

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.

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

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.

On 12 September 2017 at 14:04, Christoph M. Becker <[email protected]> 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.

On Tue, Sep 12, 2017 at 6:52 AM, François Laupretre
<[email protected]> 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.

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

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

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.

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

On Tue, Sep 12, 2017 at 5:02 AM, Christoph M. Becker <[email protected]> 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.

On 12 September 2017 17:45:46 BST, Levi Morrison <[email protected]> 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.

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

On Tue, Sep 12, 2017 at 7:43 PM, Stanislav Malyshev <[email protected]> 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.

On Tue, Sep 12, 2017 at 11:59 AM, Rowan Collins <[email protected]> wrote:
> On 12 September 2017 17:45:46 BST, Levi Morrison <[email protected]> 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...

> On Tue, Sep 12, 2017 at 7:43 PM, Stanislav Malyshev <[email protected]> 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.

> On Tue, Sep 12, 2017 at 6:52 AM, François Laupretre
> <[email protected]> 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:

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

"Sara Golemon" wrote in message
news:[email protected]om...
>
>On Tue, Sep 12, 2017 at 5:02 AM, Christoph M. Becker <[email protected]>
>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.

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

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

Regards,
On 12 September 2017 21:35:51 BST, Levi Morrison <[email protected]> wrote:
>On Tue, Sep 12, 2017 at 11:59 AM, Rowan Collins
><[email protected]> 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:

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

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.

On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston <[email protected]> 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:

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

> On 13 September 2017 14:15:43 BST, Ryan Pallas <[email protected]>
> 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.

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

"Levi Morrison" wrote in message
news:CAFMT4NrC43y-nL_V85q[email protected]
>
>On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston <[email protected]>
>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 .

"Ryan Pallas" wrote in message
news:[email protected]om...
>
>On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston <[email protected]>
>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.

On Wed, Sep 13, 2017 at 8:59 AM, Tony Marston <[email protected]> wrote:
> "Sara Golemon" wrote in message
> news:[email protected]om...
>> +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 Golemon" wrote in message
news:[email protected]om...
>
>On Wed, Sep 13, 2017 at 8:59 AM, Tony Marston <[email protected]>
>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"" wrote in message news:[email protected]
>
>"Levi Morrison" wrote in message
>news:[email protected]om...
>>
>>On Wed, Sep 13, 2017 at 2:59 AM, Tony Marston <[email protected]>
>>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.

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.

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.