Deprecate and remove case-insensitive constants?

  100535
September 12, 2017 12:02 cmbecker69@gmx.de ("Christoph M. Becker")
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?

-- 
Christoph M. Becker
  100537
September 12, 2017 12:52 francois@tekwire.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)
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
  100539
September 12, 2017 13:04 cmbecker69@gmx.de ("Christoph M. Becker")
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
  100540
September 12, 2017 14:04 danack@basereality.com (Dan Ackroyd)
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
  100657
September 16, 2017 03:22 yohgaki@ohgaki.net (Yasuo Ohgaki)
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
  100541
September 12, 2017 14:52 levim@php.net (Levi Morrison)
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.
  100542
September 12, 2017 14:55 levim@php.net (Levi Morrison)
> 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.
  100544
September 12, 2017 16:17 rowan.collins@gmail.com (Rowan Collins)
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]
  100545
September 12, 2017 16:45 levim@php.net (Levi Morrison)
> 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.
  100548
September 12, 2017 17:59 rowan.collins@gmail.com (Rowan Collins)
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]
  100551
September 12, 2017 20:35 levim@php.net (Levi Morrison)
On Tue, Sep 12, 2017 at 11:59 AM, Rowan Collins 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...
  100559
September 13, 2017 13:48 rowan.collins@gmail.com (Rowan Collins)
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 >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]
  100553
September 12, 2017 21:32 cmbecker69@gmx.de ("Christoph M. Becker")
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 b.php 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
  100538
September 12, 2017 12:53 me@kelunik.com (Niklas Keller)
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
  100547
September 12, 2017 17:05 pollita@php.net (Sara Golemon)
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
  100557
September 13, 2017 08:59 TonyMarston@hotmail.com ("Tony Marston")
"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
  100558
September 13, 2017 13:15 derokorian@gmail.com (Ryan Pallas)
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.
> 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 > >
  100561
September 13, 2017 14:06 rowan.collins@gmail.com (Rowan Collins)
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]
  100563
September 13, 2017 15:50 derokorian@gmail.com (Ryan Pallas)
On Wed, Sep 13, 2017 at 8:06 AM, Rowan Collins 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
> > 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] >
  100565
September 13, 2017 16:12 TonyMarston@hotmail.com ("Tony Marston")
"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
  100560
September 13, 2017 13:59 lester@lsces.co.uk (Lester Caine)
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
  100562
September 13, 2017 15:16 levim@php.net (Levi Morrison)
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
  100564
September 13, 2017 16:03 TonyMarston@hotmail.com ("Tony Marston")
"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
  100576
September 14, 2017 09:23 TonyMarston@hotmail.com ("Tony Marston")
""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
  100578
September 14, 2017 12:02 rowan.collins@gmail.com (Rowan Collins)
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]
  100658
September 16, 2017 08:57 TonyMarston@hotmail.com ("Tony Marston")
"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
  100566
September 13, 2017 17:24 pollita@php.net (Sara Golemon)
On Wed, Sep 13, 2017 at 8:59 AM, Tony Marston <TonyMarston@hotmail.com> wrote:
> "Sara Golemon" wrote in message > news:CAESVnVpUkM_W9xF+0Qt=2M61dGy40gtOehFo=U_F3gd87rmxrQ@mail.gmail.com... >> +0.1 to removing case-insensitive constants, though we'd need to >> define both "null" and "NULL" (similar for true and false) since >> there's little consensus on which version of these constants get used >> from project to project. Also: While deprecating for 7.3 is fine, I'd >> favor waiting for 8.0 for full removal. >> >> As to François' suggestion to make the whole language case-sensitive? >> Yeesh, that feels like a much more aggressive movement. In the case >> of constants they very nearly are case-sensitive only since, as you >> point out, common practice is to not pass true for that third >> parameter, and to prefer `const` over `define` anyway. Identifiers >> are another matter since they're insensitive by default. >> >> In the case of classnames I could almost get on board since >> autoloading standards have pushed users naturally in the direction of >> respecting case sensitive as a coding standard. I don't feel as >> though that's true of functions or of projects where autoloaders >> aren't used (not a small number). > > > You seem to forget that autoloading is an option, not a requirement. > I don't forget any such thing. I noted it as a phenomenon which has
*pushed* users in a particular direction, but by no means have all users gone that way, as you note about yourself. Indeed, I have a 10 year old framework still in use at a previous company which does many similar things for many similar reasons. I also stated that I could *almost* get on board. Almost is not 100%, it's arguably not even 50% since it implies not actually crossing some minimum required threshold.
> - I don't like the way autoloaders work - all my class names are in snake > case (lowercase with underscore separators) and the autoloader converts '_' > into '/' thus producing a file path which does not exist. > Nit; That's autoloader specific. PSR-0 defines that behavior, but
PSR-4 does not, for example.
> By convention I always use uppercase for constants which makes them > instantly recognisable in my code as all other names are either completely > lowercase or mixed case. Making constants case sensitive instead of > insensitive would not affect me. > Agreed, nor I suspect would it effect most other users regardless of
which case they use since the trend is to not use case-insensitive constants in the first place.
> People who think that case sensitive software is cool are deluding > themselves. When I started working on mainframe computers (UNIVAC and IBM) > in the early 1970s everything was case-insensitive. This was only changed by > people who did not understand the ramifications of their choice. > Yeah, decades of C/C++/Java developers are so dumb, like... fer reals.
Friggin' script kiddies, the lot of 'em. -Sara
  100575
September 14, 2017 09:20 TonyMarston@hotmail.com ("Tony Marston")
"Sara Golemon"  wrote in message 
news:CAESVnVp6OKB64WuO9iKEP=L9-QrrFjS+kcoeKYKULRUff-RitQ@mail.gmail.com...
> >On Wed, Sep 13, 2017 at 8:59 AM, Tony Marston <TonyMarston@hotmail.com> >wrote:
>> People who think that case sensitive software is cool are deluding >> themselves. When I started working on mainframe computers (UNIVAC and >> IBM) >> in the early 1970s everything was case-insensitive. This was only changed >> by >> people who did not understand the ramifications of their choice. >> >Yeah, decades of C/C++/Java developers are so dumb, like... fer reals. >Friggin' script kiddies, the lot of 'em. > >-Sara
If the first programming languages in the first computers were case insensitive, then that should be the standard. Those who introduced case sensitive languages at a later date should be forced to justify that decision. It is the same for file systems - all the pre-unix systems I worked on were case insensitive, as have been all versions of Microsoft Windows. Then unix came along and FUBAR'd everything. Any advantages of case sensitive systems are ALWAYS outweighed by their disadvantages. A similar cockup occurred with line endings. The original convention on teletypes was to use line-feed (LF) and carriage-return (CR) together which have separate meanings and could either be used independently or together. Then some clueless newbies came along and changed everything so that some OSes use just LF while others use just just CR. This now causes problems when transferring files from one OS to another. This shows what happens when "friggin' script kiddies" (your words, not mine) come up with an idea without understanding what the current convention is. -- Tony Marston
  100577
September 14, 2017 09:40 daniel@honestempire.com (Daniel Morris)
On Thu, 14 Sep 2017, at 10:20 AM, Tony Marston wrote:
> If the first programming languages in the first computers were case > insensitive, then that should be the standard. Those who introduced case > sensitive languages at a later date should be forced to justify that > decision.
If the first vehicles had two wheels, then that should be the standard. Those who introduced cars with four wheels should be forced to justify that decision. If the first television was black and white, then that should be the standard. Those who introduced televisions with colour should be forced to justify that decision. If the first living organisms had single cells, then that should be the standard. Evolution should be forced to justify the decision to move to multiple cells. If light exists as a wave, then that should be the standard. When an observer collapses the wave function, then they should be forced to justify that decision. -- Daniel Morris daniel@honestempire.com
  100581
September 14, 2017 12:59 TonyMarston@hotmail.com ("Tony Marston")
"Daniel Morris"  wrote in message 
news:1505382004.4078127.1105791680.3A06C2FA@webmail.messagingengine.com...
> >On Thu, 14 Sep 2017, at 10:20 AM, Tony Marston wrote: >> If the first programming languages in the first computers were case >> insensitive, then that should be the standard. Those who introduced case >> sensitive languages at a later date should be forced to justify that >> decision. > >If the first vehicles had two wheels, then that should be the standard. >Those who introduced cars with four wheels should be forced to justify >that decision. > >If the first television was black and white, then that should be the >standard. Those who introduced televisions with colour should be forced >to justify that decision. > >If the first living organisms had single cells, then that should be the >standard. Evolution should be forced to justify the decision to move to >multiple cells. > >If light exists as a wave, then that should be the standard. When an >observer collapses the wave function, then they should be forced to >justify that decision. > >-- >Daniel Morris >daniel@honestempire.com
You are being deliberately awkward. While things can progress, change, improve and be added to over time, I can see no justification for removing a facility or capability just for the convenience of a miniscule number of developers. Just because the first Ford motor cars were black is no justification for saying that all cars should be black. The idea that all cars should have their ability to steer around bends be removed just because the car makers find it easier to build cars that can only run in straight lines would be just plain nonsense. Introducing case sensitivity into what is mostly a case-insensitive world just for the convenience of a few programmers I do not consider to be acceptable. It would cause more problems for far more people than the insignificant few who insist on using obscure character sets. Why should the English-speaking world be forced to suffer just because some minor languages cannot handle case folding? If the problem has already been solved with UTF8 then no other solution should be required. If the support for UTF8 needs to be enhanced in PHP then enhance it. Do not remove case-insensitive software just because it is "convenient". As was said in a Star Trek movie - the needs of the many outweigh the needs of the few. -- Tony Marston
  100585
September 14, 2017 13:27 cmbecker69@gmx.de ("Christoph M. Becker")
On 14.09.2017 at 14:59, Tony Marston wrote:

> Introducing case sensitivity into what is mostly a case-insensitive > world just for the convenience of a few programmers I do not consider to > be acceptable. It would cause more problems for far more people than the > insignificant few who insist on using obscure character sets. Why should > the English-speaking world be forced to suffer just because some minor > languages cannot handle case folding?
This is not about an "insignificant few who insist on using obscure character sets", but rather about a language spoken by millions of people which has to "I" characters, namely dotted and dotless "I". Rather consistently, the dotless "I"'s lower-case variant is "ı", and the dotted "İ"'s lower-case variant is "i". There you go. -- Christoph M. Becker
  100588
September 14, 2017 13:36 TonyMarston@hotmail.com ("Tony Marston")
""Christoph M. Becker""  wrote in message 
news:98ab178e-b999-7e36-5ff5-7b8c28fe0dd4@gmx.de...
> >On 14.09.2017 at 14:59, Tony Marston wrote: > >> Introducing case sensitivity into what is mostly a case-insensitive >> world just for the convenience of a few programmers I do not consider to >> be acceptable. It would cause more problems for far more people than the >> insignificant few who insist on using obscure character sets. Why should >> the English-speaking world be forced to suffer just because some minor >> languages cannot handle case folding? > >This is not about an "insignificant few who insist on using obscure >character sets", but rather about a language spoken by millions of >people which has to "I" characters, namely dotted and dotless "I". >Rather consistently, the dotless "I"'s lower-case variant is "i", and >the dotted "I"'s lower-case variant is "i". There you go. >
The number of people in the world who use character sets which do not have this problem far outnumber those who use character sets which do have this problem. People without this problem far outnumber the others, so it would not be a good idea to inconvenience the many just to satisfy the few. -- Tony Marston
  100590
September 14, 2017 13:46 addw@phcomp.co.uk (Alain Williams)
On Thu, Sep 14, 2017 at 02:36:27PM +0100, Tony Marston wrote:
> ""Christoph M. Becker"" wrote in message > news:98ab178e-b999-7e36-5ff5-7b8c28fe0dd4@gmx.de... > > > >On 14.09.2017 at 14:59, Tony Marston wrote: > > > >>Introducing case sensitivity into what is mostly a case-insensitive > >>world just for the convenience of a few programmers I do not consider to > >>be acceptable. It would cause more problems for far more people than the > >>insignificant few who insist on using obscure character sets. Why should > >>the English-speaking world be forced to suffer just because some minor > >>languages cannot handle case folding? > > > >This is not about an "insignificant few who insist on using obscure > >character sets", but rather about a language spoken by millions of > >people which has to "I" characters, namely dotted and dotless "I". > >Rather consistently, the dotless "I"'s lower-case variant is "i", and > >the dotted "I"'s lower-case variant is "i". There you go. > > > > The number of people in the world who use character sets which do > not have this problem far outnumber those who use character sets > which do have this problem. People without this problem far > outnumber the others, so it would not be a good idea to > inconvenience the many just to satisfy the few.
Translation: I do not use these character sets, those who do are not important. PHP (& File systems) are best staying away from things like that. Not attempting case folding, and similar, makes it simpler, faster & more robust (not worrying about what sort of 'i' to convert to). It only helps those who do not know what the SHIFT key is for. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include
  100610
September 15, 2017 09:02 TonyMarston@hotmail.com ("Tony Marston")
"Alain Williams"  wrote in message 
news:20170914134603.GS8096@phcomp.co.uk...
> >On Thu, Sep 14, 2017 at 02:36:27PM +0100, Tony Marston wrote: >> ""Christoph M. Becker"" wrote in message >> news:98ab178e-b999-7e36-5ff5-7b8c28fe0dd4@gmx.de... >> > >> >On 14.09.2017 at 14:59, Tony Marston wrote: >> > >> >>Introducing case sensitivity into what is mostly a case-insensitive >> >>world just for the convenience of a few programmers I do not consider >> >>to >> >>be acceptable. It would cause more problems for far more people than >> >>the >> >>insignificant few who insist on using obscure character sets. Why >> >>should >> >>the English-speaking world be forced to suffer just because some minor >> >>languages cannot handle case folding? >> > >> >This is not about an "insignificant few who insist on using obscure >> >character sets", but rather about a language spoken by millions of >> >people which has to "I" characters, namely dotted and dotless "I". >> >Rather consistently, the dotless "I"'s lower-case variant is "i", and >> >the dotted "I"'s lower-case variant is "i". There you go. >> > >> >> The number of people in the world who use character sets which do >> not have this problem far outnumber those who use character sets >> which do have this problem. People without this problem far >> outnumber the others, so it would not be a good idea to >> inconvenience the many just to satisfy the few. > >Translation: I do not use these character sets, those who do are not >important.
Incorrect. The proper question is: How any character sets have this problem? What percentage of the world's computer users are affected by this problem? If this number is quite small then it would be wrong to make the majority suffer just because you don't know how to fix the problem that affects the minority.
>PHP (& File systems) are best staying away from things like that.
Microsoft produces case insensitive software, including file systems, because that is what users are used to. Unix was invented in a laboratory by academics who couldn't develop case insensitive software so they called it a "feature" and not a "bug".
> Not attempting >case folding, and similar, makes it simpler, faster & more robust (not >worrying >about what sort of 'i' to convert to). It only helps those who do not know >what >the SHIFT key is for.
Why is it not possible to identify a single upper and lower case variant for every character in every character set? -- Tony Marston
  100623
September 15, 2017 12:44 lester@lsces.co.uk (Lester Caine)
On 15/09/17 10:02, Tony Marston wrote:
> Why is it not possible to identify a single upper and lower case variant > for every character in every character set?
Can't find the right unicode standard page, but https://www.elastic.co/guide/en/elasticsearch/guide/current/case-folding.html sums it up. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  100631
September 15, 2017 14:54 TonyMarston@hotmail.com ("Tony Marston")
"Lester Caine"  wrote in message 
news:55603872-e832-65ea-25b6-48e01074a4c7@lsces.co.uk...
> >On 15/09/17 10:02, Tony Marston wrote: >> Why is it not possible to identify a single upper and lower case variant >> for every character in every character set? > >Can't find the right unicode standard page, but >https://www.elastic.co/guide/en/elasticsearch/guide/current/case-folding.html >sums it up. >
Try this page: http://unicode.org/faq/casemap_charprop.html Notice that case folding for case insensitive comparisons is relatively easy when compared with case switching. -- Tony Marston
  100586
September 14, 2017 13:27 rowan.collins@gmail.com (Rowan Collins)
On 14 September 2017 13:59:20 BST, Tony Marston <TonyMarston@hotmail.com> wrote:
> Why should the >English-speaking world be forced to suffer just because some minor >languages >cannot handle case folding?
Have you any idea how arrogant this sounds? Why should "the English-speaking world" get to make up the rules? What criteria make something "a minor language"? Who gave you the right to make such lofty pronouncements? And, please, stop muddling UTF8, a particular way of representing text in binary, with Unicode, the huge and complex standard that attempts to handle fairly these "minor languages" which you dismiss so casually. Or preferably just stop commenting on topics you so obviously don't understand. Regards, -- Rowan Collins [IMSoP]
  100591
September 14, 2017 13:48 TonyMarston@hotmail.com ("Tony Marston")
"Rowan Collins"  wrote in message 
news:7394E3CE-B05A-474E-8AB5-A651FDD35232@gmail.com...
> >On 14 September 2017 13:59:20 BST, Tony Marston <TonyMarston@hotmail.com> >wrote: >> Why should the >>English-speaking world be forced to suffer just because some minor >>languages >>cannot handle case folding? > >Have you any idea how arrogant this sounds? Why should "the >English-speaking world" get to make up the rules? What criteria make >something "a minor language"? Who gave you the right to make such lofty >pronouncements?
Because the English-speaking world invented both computers and the languages used to program them. The early ASCII character set supported only the English/American languages, and while other languages were supported on an ad hoc basis with specific character sets, the creation of a single UNICODE standard to cover all possible character sets was later created and should be available in all languages. If UNICODE solves all particular issues regarding case-insensitive software, but has yet to be properly implemented in PHP, then the correct response to this problem would be to rectify PHP's implementation.
>And, please, stop muddling UTF8, a particular way of representing text in >binary, with Unicode, the huge and complex standard that attempts to handle >fairly these "minor languages" which you dismiss so casually. Or preferably >just stop commenting on topics you so obviously don't understand.
The terms "UTF8" and "UNICODE" do not mean entirely different things. The page at https://en.wikipedia.org/wiki/UTF-8 speaks of "UTF-8-encoded Unicode", so for may people they are just different sides of the same coin. -- Tony Marston
  100593
September 14, 2017 13:55 addw@phcomp.co.uk (Alain Williams)
On Thu, Sep 14, 2017 at 02:48:06PM +0100, Tony Marston wrote:
> "Rowan Collins" wrote in message > news:7394E3CE-B05A-474E-8AB5-A651FDD35232@gmail.com... > > > >On 14 September 2017 13:59:20 BST, Tony Marston > ><TonyMarston@hotmail.com> wrote: > >>Why should the > >>English-speaking world be forced to suffer just because some minor > >>languages > >>cannot handle case folding? > > > >Have you any idea how arrogant this sounds? Why should "the > >English-speaking world" get to make up the rules? What criteria > >make something "a minor language"? Who gave you the right to make > >such lofty pronouncements? > > Because the English-speaking world invented both computers and the > languages used to program them.
The light bulb was invented by an English man (Joseph Swan), the television by a Scott (John Logie Baird); so should the Brits and Scots be the ones that define light bulb and TV standards to suit their convenience ? -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include
  100611
September 15, 2017 09:04 TonyMarston@hotmail.com ("Tony Marston")
"Alain Williams"  wrote in message 
news:20170914135519.GW8096@phcomp.co.uk...
> >On Thu, Sep 14, 2017 at 02:48:06PM +0100, Tony Marston wrote: >> "Rowan Collins" wrote in message >> news:7394E3CE-B05A-474E-8AB5-A651FDD35232@gmail.com... >> > >> >On 14 September 2017 13:59:20 BST, Tony Marston >> ><TonyMarston@hotmail.com> wrote: >> >>Why should the >> >>English-speaking world be forced to suffer just because some minor >> >>languages >> >>cannot handle case folding? >> > >> >Have you any idea how arrogant this sounds? Why should "the >> >English-speaking world" get to make up the rules? What criteria >> >make something "a minor language"? Who gave you the right to make >> >such lofty pronouncements? >> >> Because the English-speaking world invented both computers and the >> languages used to program them. > >The light bulb was invented by an English man (Joseph Swan), the television >by a >Scott (John Logie Baird); so should the Brits and Scots be the ones that >define >light bulb and TV standards to suit their convenience ? >
Don't be silly. Neither light bulbs nor television sets are affected by which case is used in which character set. -- Tony Marston
  100594
September 14, 2017 14:05 daniel@honestempire.com (Daniel Morris)
On Thu, 14 Sep 2017, at 02:48 PM, Tony Marston wrote: 
> Because the English-speaking world invented both computers and the > languages used to program them.
It was a German that invented binary, so my suggestion is to devolve all future decisions to the Germans. On Thu, 14 Sep 2017, at 02:36 PM, Tony Marston wrote:
> The number of people in the world who use character sets which do > not have this problem far outnumber those who use character sets > which do have this problem. People without this problem far > outnumber the others, so it would not be a good idea to > inconvenience the many just to satisfy the few.
You are nearly always a minority opinion, the irony of you writing this whilst at the same time asking the world to slow down so that your stubborn fourteen year old framework can catch up beggars belief. -- Daniel Morris daniel@honestempire.com
  100612
September 15, 2017 09:12 TonyMarston@hotmail.com ("Tony Marston")
"Daniel Morris"  wrote in message 
news:1505397937.4137791.1106049000.16B8878B@webmail.messagingengine.com...
> >On Thu, 14 Sep 2017, at 02:48 PM, Tony Marston wrote: >> Because the English-speaking world invented both computers and the >> languages used to program them. > >It was a German that invented binary, so my suggestion is to devolve all >future decisions to the Germans.
Binary coding is not affected by changes in case so this argument is bogus.
>On Thu, 14 Sep 2017, at 02:36 PM, Tony Marston wrote: >> The number of people in the world who use character sets which do >> not have this problem far outnumber those who use character sets >> which do have this problem. People without this problem far >> outnumber the others, so it would not be a good idea to >> inconvenience the many just to satisfy the few. > >You are nearly always a minority opinion, the irony of you writing this >whilst at the same time asking the world to slow down so that your >stubborn fourteen year old framework can catch up beggars belief.
I am not asking the world to slow down because I am too lazy to change. I am arguing that case insensitive software has been around for many decades, and for some people to advocate for its removal just because they don't have the brain power to come up with a proper solution for a minor glitch that affects only a small number of languages I find unacceptable. A competent programmer would fix the problem that affects the few without removing a feature that the many are used to. -- Tony Marston
  100614
September 15, 2017 09:21 addw@phcomp.co.uk (Alain Williams)
On Fri, Sep 15, 2017 at 10:04:51AM +0100, Tony Marston wrote:

> >The light bulb was invented by an English man (Joseph Swan), the > >television by a > >Scott (John Logie Baird); so should the Brits and Scots be the > >ones that define > >light bulb and TV standards to suit their convenience ? > > > > Don't be silly. Neither light bulbs nor television sets are affected > by which case is used in which character set.
> >>Because the English-speaking world invented both computers and the > >>languages used to program them. > > > >It was a German that invented binary, so my suggestion is to devolve all > >future decisions to the Germans. > > Binary coding is not affected by changes in case so this argument is bogus.
I think that both Rowan Collins & I agree on that point. We were commenting on your assertion:
> >>Because the English-speaking world invented both computers and the > >>languages used to program them. > >
Thus because we are English speaking we do not have a special position to dictate the development of computers and languages -- especially as it affects non-English speakers. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include
  100625
September 15, 2017 14:15 TonyMarston@hotmail.com ("Tony Marston")
"Alain Williams"  wrote in message 
news:20170915092114.GH8096@phcomp.co.uk...
> >On Fri, Sep 15, 2017 at 10:04:51AM +0100, Tony Marston wrote: > >> >The light bulb was invented by an English man (Joseph Swan), the >> >television by a >> >Scott (John Logie Baird); so should the Brits and Scots be the >> >ones that define >> >light bulb and TV standards to suit their convenience ? >> > >> >> Don't be silly. Neither light bulbs nor television sets are affected >> by which case is used in which character set. > > >> >>Because the English-speaking world invented both computers and the >> >>languages used to program them. >> > >> >It was a German that invented binary, so my suggestion is to devolve all >> >future decisions to the Germans. >> >> Binary coding is not affected by changes in case so this argument is >> bogus. > > >I think that both Rowan Collins & I agree on that point. We were commenting >on >your assertion: > >> >>Because the English-speaking world invented both computers and the >> >>languages used to program them. >> > > >Thus because we are English speaking we do not have a special position to >dictate the development of computers and languages -- especially as it >affects >non-English speakers.
You are missing the point. The convention in the whole of the English-speaking world is exactly the same - it has both upper and lower case characters, and the meaning of a word does not change simply because some characters are written in a different case. When a person searches for a word in a dictionary he is not bothered about case. When a person searches for a file in the Windows OS he is not bothered about case. When a person searches for a word inside a file he is not bothered about case. I has seen some search mechanisms which provide the option to make the search case sensitive, but that is an option which has to be turned on - the default is still case insensitive. Can you show me any dictionary in ANY language where the same word has different meanings just by changing the case of one or more characters? Can you show me any language where a single character has multiple alternatives when switching case? By my reckoning case insensitivity has been the default way before computers were invented, and all the software on the early computers was also case insensitive. I have worked on numerous hardware platforms since the 1970s, and they were ALL case insensitive. -- Tony Marston
  100627
September 15, 2017 14:27 lists@rhsoft.net ("lists@rhsoft.net")
Am 15.09.2017 um 16:15 schrieb Tony Marston:
> Can you show me any language where a single character has multiple > alternatives when switching case?
http://cdn.webfail.com/upl/img/07181c2ca27/post2.jpg _____________________________________ german: Sie ist wirklich gut zu Vögeln english: she is really nice to birds german: Sie ist wirkich gut zu vögeln english: she is really nice to fuck _____________________________________ german: Ich wünschte er wäre Dichter! english: i wish he would be a poet german: Ich ünschte er wäre dichter! english: i wish he would be more drunken _____________________________________ and now stop it!
  100659
September 16, 2017 09:16 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:c257f203-2c8e-f6d3-f5cd-597310957755@rhsoft.net...
> > > >Am 15.09.2017 um 16:15 schrieb Tony Marston: >> Can you show me any language where a single character has multiple >> alternatives when switching case? > >http://cdn.webfail.com/upl/img/07181c2ca27/post2.jpg >_____________________________________ > >german: Sie ist wirklich gut zu Vögeln >english: she is really nice to birds > >german: Sie ist wirkich gut zu vögeln >english: she is really nice to fuck >_____________________________________ > >german: Ich wünschte er wäre Dichter! >english: i wish he would be a poet > >german: Ich ünschte er wäre dichter! >english: i wish he would be more drunken >_____________________________________ > >and now stop it!
Even in the English language there are words which which can have different meanings depending on the context, but there are NO circumstances where a word means one thing when it is in lowercase and something else when it is in uppercase. The rules change when several words are grouped together in a sentence. For example, the sentence "He is pissed" can have two possible meanings: pissed - meaning "drunk" pissed - meaning "pissed off" or "unhappy" There is no such thing as "Pissed with a capital 'P' means drunk" and "pissed with a lowercase 'p' means unhappy". The idea that the entire universe should have to change its rules regarding switching between upper and lowercase just to satisfy a few anomalies concocted by the master race is laughable. -- Tony Marston
  100670
September 16, 2017 09:54 cmbecker69@gmx.de ("Christoph M. Becker")
On 16.09.2017 at 11:16, Tony Marston wrote:

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

> I have already acknowledged that the same word can have a different > meaning in a different context, so the word "china" has a different > meaning in "I am going to China" and "this is made from china". However, > in the same context changes in case are irrelevant: > > "I AM GOING TO CHINA" is the same as "i am going to china". > "THIS IS MADE FROM CHINA" is the same as "this is made from china".
The same written (and this is what we're talking about; pronunciation is irrelevant here) English word can have different meaning in the same context, too. One may say "This is nice!" (to show appreciation) and "This is Nice!" (to refer to the city). Also many professions which are also common names have the same issue ("This is the miller" vs. "This is the Miller"). You may recognize the common pattern, namely that proper names are capitalized in English. In German, and likely some other languages as well, all nouns are capitalized, so there are obviously many more such cases. However, that does not necessarily mean that I prefer case-sensivity over case-insensivity, but it would indeed greatly simplify the implementation, since case-folding is a rather complex issue. For instance, the German lower-case letter "ß" is traditionally written as "SS" in upper-case. So if I would define('STRASSE', $value, true), I might expect to be able to write "Straße". That wouldn't apply to "KRESSE", though, which has to be written as "Kresse". See also <https://www.w3.org/International/wiki/Case_folding>. -- Christoph M. Becker
  100704
September 19, 2017 09:24 TonyMarston@hotmail.com ("Tony Marston")
""Christoph M. Becker""  wrote in message 
news:e8590cd8-8e85-9f2f-470f-f612b2b0fee8@gmx.de...
> >On 18.09.2017 at 11:40, Tony Marston wrote: > >> I have already acknowledged that the same word can have a different >> meaning in a different context, so the word "china" has a different >> meaning in "I am going to China" and "this is made from china". However, >> in the same context changes in case are irrelevant: >> >> "I AM GOING TO CHINA" is the same as "i am going to china". >> "THIS IS MADE FROM CHINA" is the same as "this is made from china". > >The same written (and this is what we're talking about; pronunciation is >irrelevant here) English word can have different meaning in the same >context, too. One may say "This is nice!" (to show appreciation) and >"This is Nice!" (to refer to the city). Also many professions which are >also common names have the same issue ("This is the miller" vs. "This is >the Miller"). You may recognize the common pattern, namely that proper >names are capitalized in English. In German, and likely some other >languages as well, all nouns are capitalized, so there are obviously >many more such cases.
You are talking about slight differences in human-to-human communication which is totally irrelevant. This topic is about switching case in software, and in such cases those differences are irrelevant. If my software switches case so that "this is nice" becomes "THIS IS NICE" or vice versa, then it does not matter one jot that "nice" could mean a place, or something pleasant, or even the initials of The National Institute for Health and Care Excellence. Inside the computer it does not matter. The fact that "title case" means different things in different languages is irrelevant. If it is implemented in the standard (i.e English) way then it does not make the sentence unreadable in those foreign languages, so those foreign johnnys should learn to live with it.
>However, that does not necessarily mean that I prefer case-sensivity >over case-insensivity, but it would indeed greatly simplify the >implementation, since case-folding is a rather complex issue.
I have always been taught that there are only two ways of doing a job - either "properly" or "not at all". The exceptions in switching between upper and lowercase should be built into the Unicode engine then the problem is solved properly. Removing case insensitivity completely is not a proper solution as it removes a feature that we humans have been used to for decades. This would be a case where the cure is even worse than the disease.
> For >instance, the German lower-case letter "ß" is traditionally written as >"SS" in upper-case. So if I would define('STRASSE', $value, true), I >might expect to be a ble to write "Straße". That wouldn't apply to >"KRESSE", though, which has to be written as "Kresse". See also ><https://www.w3.org/International/wiki/Case_folding>.
If the single character "ß" represents two "s" characters joined together, then the uppercase equivalent should also be a single character which looks like two "S" characters joined together. If it is not possible to write code which deals with these exceptions, then one alternative would be to remove these exceptions. -- Tony Marston
  100705
September 19, 2017 09:35 lists@rhsoft.net ("lists@rhsoft.net")
Am 19.09.2017 um 11:24 schrieb Tony Marston:
> If the single character  "ß" represents two "s" characters joined > together, then the uppercase equivalent should also be a single > character which looks like two "S" characters joined together. If it is > not possible to write code which deals with these exceptions, then one > alternative would be to remove these exceptions
remove from where? from the reality? have fun, it becomes even more complexer and currently it's in discussion where to place the uppercase on a keyboard https://en.wikipedia.org/wiki/%C3%9F#Capital_form > If the single character "ß" represents two "s" no, until short ago there where just no uppercase one and that's only about german - you still missed *to prove* "Removing case insensitivity completely is not a proper solution as it removes a feature that we humans have been used to for decades" since i know nobody right in his mind which writes inconsistent code where this is a real world problem and if someone writtes "my_function", "MY_function" and "my_Function" in his code and don#t stop that nosnese he simply get fired
  100709
September 20, 2017 09:30 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:098adca8-6897-929d-90e4-cc464f0e22a2@rhsoft.net...
> > > >Am 19.09.2017 um 11:24 schrieb Tony Marston: >> If the single character "ß" represents two "s" characters joined >> together, then the uppercase equivalent should also be a single character >> which looks like two "S" characters joined together. If it is not >> possible to write code which deals with these exceptions, then one >> alternative would be to remove these exceptions > >remove from where? >from the reality?
If the lowercase character "ß" causes so many problems because it has no proper equivalent in uppercase then it should be removed from the list of valid characters. Either that or provide a single uppercase character - which is what that wikipedia article you quoted says actually happened this year.
>have fun, it becomes even more complexer and currently it's in discussion >where to place the uppercase on a keyboard >https://en.wikipedia.org/wiki/%C3%9F#Capital_form > > > If the single character "ß" represents two "s" > >no, until short ago there where just no uppercase one and that's only about >german - you still missed *to prove* "Removing case insensitivity >completely is not a proper solution as it removes a feature that we humans >have been used to for decades"
When we search for a word in a dictionary we do not need to specify case as that is irrelevant, so "sausage" is the same as "SAUSAGE". There are words which can have different meanings depending on the context, such as "this cup is made of china" and "I am going to China", but provided that the context remains the same then case is irrelevant. When it comes to software case insensitivity has been the standard since day 1. When searching for a file in MS Windows you do not have to specify case as it is not possible to have different files with the same name but different mixtures of case. When searching for a word or phrase in a text editor it is not necessary to specify case, although some editors include an option to make the search case sensitive.
>since i know nobody right in his mind which writes inconsistent code where >this is a real world problem and if someone writtes "my_function", >"MY_function" and "my_Function" in his code and don#t stop that nosnese he >simply get fired
That may be uncool, but the only problem it causes is in the tiny minds of OCD sufferers. By making the language case sensitive and allowing "my_function", "MY_function" and "my_Function" to be defined as separate functions with separate implementations would be inviting total disaster. -- Tony Marston
  100712
September 20, 2017 10:07 lester@lsces.co.uk (Lester Caine)
On 20/09/17 10:30, Tony Marston wrote:
> When it comes to software case insensitivity has been the standard since > day 1. When searching for a file in MS Windows you do not have to > specify case as it is not possible to have different files with the same > name but different mixtures of case.
When M$ screwed up the filing system by allowing spaces in file names and also dropping case sensitivity - to make life easier for none programmers - we had to get use to this 'new way of working'. It STILL causes problems today so no it was NOT standard from day 1. Although I can't remember now if DOS 8.3 file names enforced uppercase only but all other OS's at that time preserved case in file names. https://en.wikipedia.org/wiki/8.3_filename explains how VFAT added longer file names to FAT ... using an upper case file name below. File capabilities on https://en.wikipedia.org/wiki/Comparison_of_file_systems will demonstrate just how few file systems are case-insensitive. You will see that NTFS is ACTUALLY case-sensitive and it is only the WIN32 subsystem which prevents file names clashes. It's also that system which changes the case of a name when it's displayed or passed over to other systems :( That all said ... the rather limited question here is if the current very restricted case-insensitivity should be removed, or should it be expanded to properly handle constant names in other character sets? That then needs a LOT of work in other areas where the limited ascii case-insensitivity is allowed? Do we NEED case-insensitivity if that is one thing preventing a switch to use of unicode names in the code? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  100713
September 20, 2017 10:07 lists@rhsoft.net ("lists@rhsoft.net")
Am 20.09.2017 um 11:30 schrieb Tony Marston:
> wrote in message news:098adca8-6897-929d-90e4-cc464f0e22a2@rhsoft.net... >> >> >> >> Am 19.09.2017 um 11:24 schrieb Tony Marston: >>> If the single character  "ß" represents two "s" characters joined >>> together, then the uppercase equivalent should also be a single >>> character which looks like two "S" characters joined together. If it >>> is not possible to write code which deals with these exceptions, then >>> one alternative would be to remove these exceptions >> >> remove from where? >> from the reality? > > If the lowercase character "ß" causes so many problems because it has no > proper equivalent in uppercase then it should be removed from the list > of valid characters. Either that or provide a single uppercase character > - which is what that wikipedia article you quoted says actually happened > this year
jesus christ the german language DID NOT have a uppercase ß in the real world until recently but had the lowercase ß virtually forever how do you imagine "removeed from the list of valid characters" in that case - frankly that paragraph above shows clearly that you should stop to argue about this topic at all
  100747
September 22, 2017 08:21 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:064eafcb-e42f-cfeb-76f1-e2c5aec0ea27@rhsoft.net...
> > > >Am 20.09.2017 um 11:30 schrieb Tony Marston: >> wrote in message news:098adca8-6897-929d-90e4-cc464f0e22a2@rhsoft.net... >>> >>> >>> >>> Am 19.09.2017 um 11:24 schrieb Tony Marston: >>>> If the single character "ß" represents two "s" characters joined >>>> together, then the uppercase equivalent should also be a single >>>> character which looks like two "S" characters joined together. If it is >>>> not possible to write code which deals with these exceptions, then one >>>> alternative would be to remove these exceptions >>> >>> remove from where? >>> from the reality? >> >> If the lowercase character "ß" causes so many problems because it has no >> proper equivalent in uppercase then it should be removed from the list of >> valid characters. Either that or provide a single uppercase character - >> which is what that wikipedia article you quoted says actually happened >> this year > >jesus christ the german language DID NOT have a uppercase ß in the real >world until recently but had the lowercase ß virtually forever > >how do you imagine "removeed from the list of valid characters" in that >case - frankly that paragraph above shows clearly that you should stop to >argue about this topic at all
Just because my opinion differs from yours does not give you the right to demand that I stop expressing it. To me the situation is quite simple. - Human beings have grown accustomed to case-insensitive world, and to remove this standard feature would cause great disruption. - Some people may think that function names written as "do_something" or "do_Something" or "Do_Something" which mean the same thing are wrong, but that is no more than simply irritating for the nit-picking minority. If you made those names mean different thing then that would be worse than wrong, it would be criminally insane. - Rather than making constants case sensitive it would be better to leave then as case insensitive, but prevent the creation of a constant with the same name but different case. This would make it consistent with function and method names. - If the use of some non-ASCII characters in function names causes case folding problems then I see two choices - either disallow non-ASCII characters in function names, or allow Unicode characters but disallow any which have case folding problems. Simply telling me that it would be easier to make the entire language case sensitive as there are "difficulties" with case folding of a minute number of unicode characters is not good enough. Programmers are supposed to solve problems for their users, not create them. -- Tony Marston
  100748
September 22, 2017 10:37 lists@rhsoft.net ("lists@rhsoft.net")
Am 22.09.2017 um 10:21 schrieb Tony Marston:
> wrote in message news:064eafcb-e42f-cfeb-76f1-e2c5aec0ea27@rhsoft.net... >>>> Am 19.09.2017 um 11:24 schrieb Tony Marston: >>>>> If the single character  "ß" represents two "s" characters joined >>>>> together, then the uppercase equivalent should also be a single >>>>> character which looks like two "S" characters joined together. If >>>>> it is not possible to write code which deals with these exceptions, >>>>> then one alternative would be to remove these exceptions >>>> >>>> remove from where? >>>> from the reality? >>> >>> If the lowercase character "ß" causes so many problems because it has >>> no proper equivalent in uppercase then it should be removed from the >>> list of valid characters. Either that or provide a single uppercase >>> character - which is what that wikipedia article you quoted says >>> actually happened this year >> >> jesus christ the german language DID NOT have a uppercase ß in the >> real world until recently but had the lowercase ß virtually forever >> >> how do you imagine "removeed from the list of valid characters" in >> that case - frankly that paragraph above shows clearly that you should >> stop to argue about this topic at all > > Just because my opinion differs from yours does not give you the right > to demand that I stop expressing it
surely, in my opinion you don't understand the topic you are talking about and repeating the same questionable stuff again and again and as you are allowed to express your opinion i am allowed to express mine the way you argued about how code consistency don't matter says it all as you call everybody which demands that code all over a poject or company has to follow a common coding style "OCD sufferers" - but hey, the others are all ghost drivers and should turn around....
  100760
September 24, 2017 09:36 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:caba6370-7531-7c51-3900-434611d000b0@rhsoft.net...
> > > >Am 22.09.2017 um 10:21 schrieb Tony Marston: >> wrote in message news:064eafcb-e42f-cfeb-76f1-e2c5aec0ea27@rhsoft.net... >>>>> Am 19.09.2017 um 11:24 schrieb Tony Marston: >>>>>> If the single character "ß" represents two "s" characters joined >>>>>> together, then the uppercase equivalent should also be a single >>>>>> character which looks like two "S" characters joined together. If it >>>>>> is not possible to write code which deals with these exceptions, then >>>>>> one alternative would be to remove these exceptions >>>>> >>>>> remove from where? >>>>> from the reality? >>>> >>>> If the lowercase character "ß" causes so many problems because it has >>>> no proper equivalent in uppercase then it should be removed from the >>>> list of valid characters. Either that or provide a single uppercase >>>> character - which is what that wikipedia article you quoted says >>>> actually happened this year >>> >>> jesus christ the german language DID NOT have a uppercase ß in the real >>> world until recently but had the lowercase ß virtually forever >>> >>> how do you imagine "removeed from the list of valid characters" in that >>> case - frankly that paragraph above shows clearly that you should stop >>> to argue about this topic at all >> >> Just because my opinion differs from yours does not give you the right to >> demand that I stop expressing it > >surely, in my opinion you don't understand the topic you are talking about >and repeating the same questionable stuff again and again and as you are >allowed to express your opinion i am allowed to express mine > >the way you argued about how code consistency don't matter says it all
It is your definition of "consistency" that I object to. Consistency with what? Code that abandons case insensitivity "just to be consistent" is consistently bad because it removes the feature called "case insensitivity" that we humans have become used to since we began to read and write. I have been working in the computer industry since the early 1970s on a variety of mainframe, mini- and micro-computers, and a variety of languages. and this was all case insensitive. It was only the invention of unix which threw a spanner in the works.
>as you call everybody which demands that code all over a poject or company >has to follow a common coding style "OCD sufferers" - but hey, the others >are all ghost drivers and should turn around....
If you wish to enforce case sensitivity in projects which you control then go ahead. Just don't try to enforce it on everybody else. -- Tony Marston
  100761
September 24, 2017 10:05 addw@phcomp.co.uk (Alain Williams)
On Sun, Sep 24, 2017 at 10:36:02AM +0100, Tony Marston wrote:

> we began to read and write. I have been working in the computer > industry since the early 1970s on a variety of mainframe, mini- and > micro-computers, and a variety of languages. and this was all case > insensitive. It was only the invention of unix which threw a spanner > in the works.
I remember those early days; things have changed. Back then case was not an issue: * ASR33 Teletypes were upper case only * Punch cards machines were upper case only Yes: you could sometimes get lower case, but it was hard. Case conversion was easy: * ASCII - 7 bit characters, easy * EBCDIC - 8 bit characters, easy (OK: national variants of ASCII/EBCDIC, but still 7/8 bit). Some machines, eg CDC, had 6 bit character set - upper case only. These days we use Unicode, a 21 bit character set. Case conversion is hard and, as others have explained, can be ambiguous, non-reversible, ...
> If you wish to enforce case sensitivity in projects which you > control then go ahead. Just don't try to enforce it on everybody > else.
May I suggest that you create your own fork of PHP and leave the rest of us alone. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include
  100763
September 24, 2017 10:52 lester@lsces.co.uk (Lester Caine)
On 24/09/17 11:05, Alain Williams wrote:
>> we began to read and write. I have been working in the computer >> industry since the early 1970s on a variety of mainframe, mini- and >> micro-computers, and a variety of languages. and this was all case >> insensitive. It was only the invention of unix which threw a spanner >> in the works. > I remember those early days; things have changed. Back then case was not an issue: > > * ASR33 Teletypes were upper case only > > * Punch cards machines were upper case only > > Yes: you could sometimes get lower case, but it was hard. > > Case conversion was easy: > > * ASCII - 7 bit characters, easy > > * EBCDIC - 8 bit characters, easy > > (OK: national variants of ASCII/EBCDIC, but still 7/8 bit). > > Some machines, eg CDC, had 6 bit character set - upper case only. > > These days we use Unicode, a 21 bit character set. Case conversion is hard and, > as others have explained, can be ambiguous, non-reversible, ...
That sums it up nicely Alain ... Now the question is actually ... do we stay in the dark ages of single byte character sets or do we move to fully embrace a current well established and extensively used standard. Unicode has perhaps shirked on the matter of 'case-insensitive' so there is no clean solution to that today. That should not prevent the switch to unicode and other threads such as the csv routines are now highlighting additional 'edge cases' where unicode needs addressing, or kicking into the long grass of extensions of mbstring? Maintaining 'case-insensitive' for single byte character sets is an option, but then one needs to stay with that for the whole code functionality? Allowing multibyte constant names with the current limited sub-set of case conversion is just not sensible, but in the absence of a clean unicode case folding/conversion which is the sensible next step? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  100764
September 24, 2017 12:07 addw@phcomp.co.uk (Alain Williams)
On Sun, Sep 24, 2017 at 11:52:49AM +0100, Lester Caine wrote:

> That sums it up nicely Alain ... > Now the question is actually ... do we stay in the dark ages of single > byte character sets or do we move to fully embrace a current well > established and extensively used standard. Unicode has perhaps shirked > on the matter of 'case-insensitive' so there is no clean solution to > that today. That should not prevent the switch to unicode and other > threads such as the csv routines are now highlighting additional 'edge > cases' where unicode needs addressing, or kicking into the long grass of > extensions of mbstring? Maintaining 'case-insensitive' for single byte > character sets is an option, but then one needs to stay with that for > the whole code functionality? Allowing multibyte constant names with the > current limited sub-set of case conversion is just not sensible, but in > the absence of a clean unicode case folding/conversion which is the > sensible next step?
We also need to think about how our decisions here affect how PHP is used; in particular robustness, correctness, ... of code that people write. I believe that one attribute of the mind of a good programmer is precision/exactness - eschewing sloppyness. Thus if a function is written DoSomething() then it should be spelled that way, not doSomething(), etc. Also PHP programmers are likely to write Javascript - which is case sensitive. I have also seen problems where someone has developed code using Microsoft SQL, they are then asked to port it to a case sensitive database, eg MySQL**. Or an application written on a case insensitive file system (Eg MS Windows) and then try to deploy it on Linux: only to have includes & fopens fail because they have been inconsistent in how they wrote file names. [[ I do not want to get into a discussion about the rights/wrongs of case (in)sensitive file names - we must just accept that as part of the world that we live in. ]] So encouraging the ''names are case sensitive'' meme is, IMHO, good. Then look at the internals of the PHP engine. Case insensitively adds complexity (== places for bugs to lurk) and makes it slower - name lookup happens a lot, it is not just a once off (& off line) compilation process. Some of us work hard to make the PHP engine 0.5% faster - so why make it slower with something that we can easily avoid ? Yes: case insensitivity is nice, I have that option set in my program editor search; but I am a programmer; to use PHP I have to put in a lot of effort to learn how to do things -- the same is true for any programming language. We are not talking about real end users such as my mother $$ - people who we try to make our systems usable for without having to train them. You ask what to do ? I suggest that case insensitiveness in single byte character sets (constant & function names) should be depricated, but enabled for one major release with an init flag -- just as was done for register_globals. That would give everyone a couple of years to tidy their code up. Then kill case insensitve anything in PHP [[ other than the likes of strcasecmp() ]]. **OK: MySQL has a switch to make table names, etc, case insensitive - but enabling that means a lot of testing to ensure that nothing else breaks. $$ I don't want to be rude about her, so maybe I ought to use a different group of clueless people, politicians perhaps ? :-) -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include
  100766
September 25, 2017 09:30 TonyMarston@hotmail.com ("Tony Marston")
"Alain Williams"  wrote in message 
news:20170924120754.GA4961@phcomp.co.uk...
> >On Sun, Sep 24, 2017 at 11:52:49AM +0100, Lester Caine wrote: > >> That sums it up nicely Alain ... >> Now the question is actually ... do we stay in the dark ages of single >> byte character sets or do we move to fully embrace a current well >> established and extensively used standard. Unicode has perhaps shirked >> on the matter of 'case-insensitive' so there is no clean solution to >> that today. That should not prevent the switch to unicode and other >> threads such as the csv routines are now highlighting additional 'edge >> cases' where unicode needs addressing, or kicking into the long grass of >> extensions of mbstring? Maintaining 'case-insensitive' for single byte >> character sets is an option, but then one needs to stay with that for >> the whole code functionality? Allowing multibyte constant names with the >> current limited sub-set of case conversion is just not sensible, but in >> the absence of a clean unicode case folding/conversion which is the >> sensible next step? > >We also need to think about how our decisions here affect how PHP is used; >in >particular robustness, correctness, ... of code that people write. I >believe >that one attribute of the mind of a good programmer is >precision/exactness - >eschewing sloppyness. Thus if a function is written DoSomething() then it >should >be spelled that way, not doSomething(), etc.
It does absolutely no harm i different case is used. I agree that it is wrong from a "purity" point of view, but it does NOT cause a genuine problem (except in the minds of a few nit pickers). However, the solution that you appear to support would definitely cause problems as we humans are used to living in a case insensitive world: - when we search for a word in a dictionary we do not have to specify the exact case to get an exact match. - when we search for a file on a user-friendly file system we do not have to specify the exact case to find a match. - when we search for a word inside a file we do not have to specify the exact case to find a match. Some editors provide an option for a case sensitive search, but the default is case INsensitive. What do you think is going to happen when keyboard input is replaced by voice input? Will we be able to just say a word, or will we have to spell it out character by character in order to specify the case of each? Try selling THAT idea and seehow far you get.
>Also PHP programmers are likely to write Javascript - which is case >sensitive.
The fact that some languages are case sensitive is not a valid argument for making all languages case sensitive. Most languages which came before javascript were case insensitive, so perhaps it's time for javascript to make itself consistent with those languages.
>I have also seen problems where someone has developed code using Microsoft >SQL, >they are then asked to port it to a case sensitive database, eg MySQL**.
MySQL is NOT case sensitive. I have been using it for nearly two decades, and when I construct an SQL I can use either upper or lower case without any problems.
>Or an application written on a case insensitive file system (Eg MS Windows) >and >then try to deploy it on Linux: only to have includes & fopens fail because >they >have been inconsistent in how they wrote file names. [[ I do not want to >get >into a discussion about the rights/wrongs of case (in)sensitive file >names - we >must just accept that as part of the world that we live in. ]] > >So encouraging the ''names are case sensitive'' meme is, IMHO, good. > >Then look at the internals of the PHP engine. Case insensitively adds >complexity (== places for bugs to lurk) and makes it slower - name lookup >happens a lot, it is not just a once off (& off line) compilation process.
Just because you cannot fix a feature which only causes a problem in a few cases is no excuse to remove that feature completely.
> Some >of us work hard to make the PHP engine 0.5% faster - so why make it slower >with >something that we can easily avoid ?
If keeping the language simple and fast is the objective, then why do I keep seeing RFCs which propose ways of combining several simple functions into a complex one just because the author wants to achieve something with fewer keystrokes? Making the language more complicated for the benefit of a minority, as well as creating code which is less readable, should be something that is avoided, not promoted.
>Yes: case insensitivity is nice, I have that option set in my program >editor >search; but I am a programmer; to use PHP I have to put in a lot of effort >to >learn how to do things -- the same is true for any programming language. We >are >not talking about real end users such as my mother $$ - people who we try >to >make our systems usable for without having to train them. > >You ask what to do ? > >I suggest that case insensitiveness in single byte character sets (constant >& >function names) should be depricated, but enabled for one major release >with an >init flag -- just as was done for register_globals. That would give >everyone a >couple of years to tidy their code up.
Do you realise how much of a BC break this would be? For what benefit? Just to satisfy your idea of "purity"?
>Then kill case insensitve anything in PHP [[ other than the likes of >strcasecmp() ]]. > >**OK: MySQL has a switch to make table names, etc, case insensitive - but >enabling that means a lot of testing to ensure that nothing else breaks. > >$$ I don't want to be rude about her, so maybe I ought to use a different >group >of clueless people, politicians perhaps ? :-) >
-- Tony Marston
  100762
September 24, 2017 10:07 lists@rhsoft.net ("lists@rhsoft.net")
Am 24.09.2017 um 11:36 schrieb Tony Marston:
> wrote in message news:caba6370-7531-7c51-3900-434611d000b0@rhsoft.net... >> Am 22.09.2017 um 10:21 schrieb Tony Marston: >>> wrote in message news:064eafcb-e42f-cfeb-76f1-e2c5aec0ea27@rhsoft.net... >>>>>> Am 19.09.2017 um 11:24 schrieb Tony Marston: >>>>>>> If the single character  "ß" represents two "s" characters joined >>>>>>> together, then the uppercase equivalent should also be a single >>>>>>> character which looks like two "S" characters joined together. If >>>>>>> it is not possible to write code which deals with these >>>>>>> exceptions, then one alternative would be to remove these exceptions >>>>>> >>>>>> remove from where? >>>>>> from the reality? >>>>> >>>>> If the lowercase character "ß" causes so many problems because it >>>>> has no proper equivalent in uppercase then it should be removed >>>>> from the list of valid characters. Either that or provide a single >>>>> uppercase character - which is what that wikipedia article you >>>>> quoted says actually happened this year >>>> >>>> jesus christ the german language DID NOT have a uppercase ß in the >>>> real world until recently but had the lowercase ß virtually forever >>>> >>>> how do you imagine "removeed from the list of valid characters" in >>>> that case - frankly that paragraph above shows clearly that you >>>> should stop to argue about this topic at all >>> >>> Just because my opinion differs from yours does not give you the >>> right to demand that I stop expressing it >> >> surely, in my opinion you don't understand the topic you are talking >> about and repeating the same questionable stuff again and again and as >> you are allowed to express your opinion i am allowed to express mine >> >> the way you argued about how code consistency don't matter says it all > > It is your definition of "consistency" that I object to. Consistency > with what? Code that abandons case insensitivity "just to be consistent" > is consistently bad because it removes the feature called "case > insensitivity" that we humans have become used to since we began to read > and write. I have been working in the computer industry since the early > 1970s on a variety of mainframe, mini- and micro-computers, and a > variety of languages. and this was all case insensitive. It was only the > invention of unix which threw a spanner in the works. > >> as you call everybody which demands that code all over a poject or >> company has to follow a common coding style "OCD sufferers" - but hey, >> the others are all ghost drivers and should turn around.... > > If you wish to enforce case sensitivity in projects which you control > then go ahead. Just don't try to enforce it on everybody else.
that thread was about the PHP core and NOT case-sensitive where you called people "OCD sufferers" - so don't play stupid games here when everybody can access the list archive or is knowing your attitude anyways - you have lost that game https://www.mail-archive.com/internals@lists.php.net/msg91537.html https://www.mail-archive.com/internals@lists.php.net/msg91562.html and frankly people like you arguing about code consistency are fired here from one the to the next because theri inability to write well cocumentend and readable quality code at all and they are instead coding timebombs it's one thing when you write your private crap but from the point you want your code used by somebody else you have to play with that rules
  100767
September 25, 2017 09:41 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:8bc2e400-5edd-db9c-1163-ec9878e9ece2@rhsoft.net...
> > > >Am 24.09.2017 um 11:36 schrieb Tony Marston:
>> If you wish to enforce case sensitivity in projects which you control >> then go ahead. Just don't try to enforce it on everybody else. > >that thread was about the PHP core and NOT case-sensitive where you called >people "OCD sufferers" - so don't play stupid games here when everybody can >access the list archive or is knowing your attitude anyways - you have lost >that game
The fact that some people write "do_something" or "do_Something" or "Do_Something" or even "DO_SOMETHING" and it points to a single function because of case insensitivity does NOT cause a genuine problem - except in the minds of a few nit-picking, anal retentive OCD sufferers. The REAL problem occurs when you make those four mixtures of case mean point to different functions which do different things. If you cannot tell the difference between a perceived problem and a real problem your attempts to shut me up will continue to fail.
>https://www.mail-archive.com/internals@lists.php.net/msg91537.html >https://www.mail-archive.com/internals@lists.php.net/msg91562.html > >and frankly people like you arguing about code consistency are fired here >from one the to the next because theri inability to write well cocumentend >and readable quality code at all and they are instead coding timebombs
I'm sorry, but reading code where the case of a word changes the meaning of that word will make that code LESS readable, not MORE.
>it's one thing when you write your private crap but from the point you want >your code used by somebody else you have to play with that rules
I repeat, if you want to enforce case sensitivity in those projects which you control then go ahead, but don't try to enforce it on the whole programming community. -- Tony Marston
  100768
September 25, 2017 09:49 lists@rhsoft.net ("lists@rhsoft.net")
Am 25.09.2017 um 11:41 schrieb Tony Marston:
> The fact that some people write "do_something" or "do_Something" or > "Do_Something" or even "DO_SOMETHING" and it points to a single function > because of case insensitivity does NOT cause a genuine problem - except > in the minds of a few nit-picking, anal retentive OCD sufferers
wow - sue your dealer!
> I'm sorry, but reading code where the case of a word changes the meaning > of that word will make that code LESS readable, not MORE
how comes when the same word is written over the whole codebase *identically* that for it is harder to read?
  100771
September 25, 2017 11:04 rowan.collins@gmail.com (Rowan Collins)
Tony, RH,

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

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

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

Regards,

-- 
Rowan Collins
[IMSoP]
  100774
September 26, 2017 09:00 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:489a2ea0-7b24-fedd-e496-ee662a6051b5@rhsoft.net...
> > > >Am 25.09.2017 um 11:41 schrieb Tony Marston: >> The fact that some people write "do_something" or "do_Something" or >> "Do_Something" or even "DO_SOMETHING" and it points to a single function >> because of case insensitivity does NOT cause a genuine problem - except >> in the minds of a few nit-picking, anal retentive OCD sufferers > >wow - sue your dealer! > >> I'm sorry, but reading code where the case of a word changes the meaning >> of that word will make that code LESS readable, not MORE > >how comes when the same word is written over the whole codebase >*identically* that for it is harder to read?
That is not what I said. Taking the same function name and allowing different versions to exist with different implementations would be a recipe for disaster whereas the situation which you are complaining about is nothing more than mildly annoying - except if you are a nit-picking, anal retentive OCD sufferer in which case it signals the arrival of the four horsemen of the apocalypse. -- Tony Marston
  100765
September 24, 2017 15:44 pollita@php.net (Sara Golemon)
> Ad hominem ad infinitum... > Okay kids. You're both very big boys with reasons and arguments and
you're both clearly the smartest. Now, how about we all respect that neither of you is going to convince the other. Any further bickering and name calling is just bickering and name calling. Let's pretend we're adults. -Sara
  100714
September 20, 2017 10:49 jamesbwebdev@gmail.com (Jay B)
> > That may be uncool, but the only problem it causes is in the tiny minds of > OCD sufferers. >
Once again, you are being derogatory and continue to label others, who do not share your opinion, with a mental health condition. As you have been told previously (thread - https://externals. io/message/99241#99241); What you seem not to recognise is that any person has the right to
> suggest or campaign for such a change, regardless of their age, experience > level, pay grade, nerdiness or severity of OCD. To imply otherwise is > offensive. >
It's a shame that you're unable to have a discussion, on a public mailing list, without being rude, offensive and derogatory. It'd be better if you could stay on topic rather than sharing your thoughts on the mental health of others. On Wed, Sep 20, 2017 at 10:30 AM, Tony Marston <TonyMarston@hotmail.com> wrote:
> wrote in message news:098adca8-6897-929d-90e4-cc464f0e22a2@rhsoft.net... > >> >> >> >> Am 19.09.2017 um 11:24 schrieb Tony Marston: >> >>> If the single character "ß" represents two "s" characters joined >>> together, then the uppercase equivalent should also be a single character >>> which looks like two "S" characters joined together. If it is not possible >>> to write code which deals with these exceptions, then one alternative would >>> be to remove these exceptions >>> >> >> remove from where? >> from the reality? >> > > If the lowercase character "ß" causes so many problems because it has no > proper equivalent in uppercase then it should be removed from the list of > valid characters. Either that or provide a single uppercase character - > which is what that wikipedia article you quoted says actually happened this > year. > > have fun, it becomes even more complexer and currently it's in discussion >> where to place the uppercase on a keyboard >> https://en.wikipedia.org/wiki/%C3%9F#Capital_form >> >> > If the single character "ß" represents two "s" >> >> no, until short ago there where just no uppercase one and that's only >> about german - you still missed *to prove* "Removing case insensitivity >> completely is not a proper solution as it removes a feature that we humans >> have been used to for decades" >> > > When we search for a word in a dictionary we do not need to specify case > as that is irrelevant, so "sausage" is the same as "SAUSAGE". There are > words which can have different meanings depending on the context, such as > "this cup is made of china" and "I am going to China", but provided that > the context remains the same then case is irrelevant. > > When it comes to software case insensitivity has been the standard since > day 1. When searching for a file in MS Windows you do not have to specify > case as it is not possible to have different files with the same name but > different mixtures of case. > > When searching for a word or phrase in a text editor it is not necessary > to specify case, although some editors include an option to make the search > case sensitive. > > since i know nobody right in his mind which writes inconsistent code where >> this is a real world problem and if someone writtes "my_function", >> "MY_function" and "my_Function" in his code and don#t stop that nosnese he >> simply get fired >> > > That may be uncool, but the only problem it causes is in the tiny minds of > OCD sufferers. By making the language case sensitive and allowing > "my_function", "MY_function" and "my_Function" to be defined as separate > functions with separate implementations would be inviting total disaster. > > -- > Tony Marston > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  100618
September 15, 2017 09:53 lists@rhsoft.net ("lists@rhsoft.net")
Am 15.09.2017 um 11:12 schrieb Tony Marston:
> I am not asking the world to slow down because I am too lazy to change. > I am arguing that case insensitive software has been around for many > decades, and for some people to advocate for its removal just because > they don't have the brain power to come up with a proper solution for a > minor glitch that affects only a small number of languages I find > unacceptable. A competent programmer would fix the problem that affects > the few without removing a feature that the many are used to
and a competent programmer using PHP as programming language would not define a funtion do_something() and write "Do_Something", "do_Something", "DO_something" all over his codebase the problem which makes such a change dramatic is the poor code quality of most projects and as i remeber you even fighted some months ago that a consistent coding style within a project is nothing you care about and that explains how you argue here very well -------- Weitergeleitete Nachricht -------- Betreff: Re: [PHP-DEV] Class Naming in Core Datum: Mon, 5 Jun 2017 09:14:47 +0100 Von: Tony Marston <TonyMarston@hotmail.com> An: internals@lists.php.net Seriously, can you explain in words of one syllable the precise benefits of such a consistency? Can you measure the benefits? Just because some OCD sufferers like consistency is not a good enough reason. I have been programming for over 30 years, and in that time I have had to deal with both snake_case and CamelCase, and while I personally find that snake_case is more readable, especially with names that contain more than 3 or 4 words, I have no trouble reading either. Having a mixture of styles does not cause a problem (except in the minds of OCD sufferers) so IMHO it does not require a solution. Anybody who says that they cannot work with a mixture of naming styles is either a liar or Illiterate.
  100628
September 15, 2017 14:38 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:8bbcc1fc-0d13-27d4-a04f-0a5ebda4c32e@rhsoft.net...
> >Am 15.09.2017 um 11:12 schrieb Tony Marston: >> I am not asking the world to slow down because I am too lazy to change. I >> am arguing that case insensitive software has been around for many >> decades, and for some people to advocate for its removal just because >> they don't have the brain power to come up with a proper solution for a >> minor glitch that affects only a small number of languages I find >> unacceptable. A competent programmer would fix the problem that affects >> the few without removing a feature that the many are used to > >and a competent programmer using PHP as programming language would not >define a funtion do_something() and write "Do_Something", "do_Something", >"DO_something" all over his codebase
While that may be "uncool" or even "inconsistent" it does not cause a genuine problem. But you seem to be supporting a change which would be worse than uncool, it would be downright horrific. No human language that I know of allows a word to change its meaning just by changing the case of one or more characters, and this standard behaviour was echoed in all the computer systems that I have used since the 1970s. The fact that I can create a function called do_something() and later refer to it as either Do_something(), do_Something() or even Do_SomeThing() may be annoying but it is irrelevant. Do you realise how many problems it would cause if each change in case pointed to a totally different function? Would you support anyone who proposed adding a series of functions to PHP core or an extension where every function used exactly the same words but in a different case? What will happen in the future if we move away from keyboard input towards speech input? It will not be good enough to simply say a word, you would have to spell it out character by character and specify the case of each character. Do you think that would be a good idea?
>the problem which makes such a change dramatic is the poor code quality of >most projects and as i remeber you even fighted some months ago that a >consistent coding style within a project is nothing you care about and that >explains how you argue here very well
I'm afraid that changing the way I do things just to be "consistent" with others is not a good argument when it ends up being "consistently bad".
>-------- Weitergeleitete Nachricht -------- >Betreff: Re: [PHP-DEV] Class Naming in Core >Datum: Mon, 5 Jun 2017 09:14:47 +0100 >Von: Tony Marston <TonyMarston@hotmail.com> >An: internals@lists.php.net > >Seriously, can you explain in words of one syllable the precise benefits of >such a consistency? Can you measure the benefits? Just because some OCD >sufferers like consistency is not a good enough reason. I have been >programming for over 30 years, and in that time I have had to deal with >both snake_case and CamelCase, and while I personally find that snake_case >is more readable, especially with names that contain more than 3 or 4 >words, I have no trouble reading either. Having a mixture of styles does >not cause a problem (except in the minds of OCD sufferers) so IMHO it does >not require a solution. Anybody who says that they cannot work with a >mixture of naming styles is either a liar or Illiterate.
-- Tony Marston
  100629
September 15, 2017 14:48 lists@rhsoft.net ("lists@rhsoft.net")
Am 15.09.2017 um 16:38 schrieb Tony Marston:
> wrote in message news:8bbcc1fc-0d13-27d4-a04f-0a5ebda4c32e@rhsoft.net... >> >> Am 15.09.2017 um 11:12 schrieb Tony Marston: >>> I am not asking the world to slow down because I am too lazy to >>> change. I am arguing that case insensitive software has been around >>> for many decades, and for some people to advocate for its removal >>> just because they don't have the brain power to come up with a proper >>> solution for a minor glitch that affects only a small number of >>> languages I find unacceptable. A competent programmer would fix the >>> problem that affects the few without removing a feature that the many >>> are used to >> >> and a competent programmer using PHP as programming language would not >> define a funtion do_something() and write "Do_Something", >> "do_Something", "DO_something" all over his codebase > > While that may be "uncool" or even "inconsistent" it does not cause a > genuine problem. But you seem to be supporting a change which would be > worse than uncool, it would be downright horrific. No human language > that I know of allows a word to change its meaning just by changing the > case of one or more characters
i brought you samples of german where the meanining of the same word changes *dramatically* - "nett zu Vögeln" versus "nett zu vögeln" which goes from "nice to birds" to "nice to fuck"
> and this standard behaviour was echoed > in all the computer systems that I have used since the 1970s. The fact > that I can create a function called do_something() and later refer to it > as either Do_something(), do_Something() or even Do_SomeThing() may be > annoying but it is irrelevant. Do you realise how many problems it would > cause if each change in case pointed to a totally different function?
only when one is so short-sighted as you act it's not rocket science at compile time throw a error that you are not allowed to define foo() and Foo() in the same software which has no runtime costs and after that you may even have less runtime costs because all the case-insensitive handling can be skipped and well, for the time of deprecation the compiler code with finally throws errors can issue the warnings with file and line - i assure you that going to fix that warnings takes less time than the whole discussion with you over the last days from several people
> Would you support anyone who proposed adding a series of functions to > PHP core or an extension where every function used exactly the same > words but in a different case? see above - just because you assume it's rocket scienece doesn't mean it is
  100660
September 16, 2017 09:29 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:ba7ed73b-8547-2029-7344-6705a70c6015@rhsoft.net...
> > > >Am 15.09.2017 um 16:38 schrieb Tony Marston: >> wrote in message news:8bbcc1fc-0d13-27d4-a04f-0a5ebda4c32e@rhsoft.net... >>> >>> Am 15.09.2017 um 11:12 schrieb Tony Marston: >>>> I am not asking the world to slow down because I am too lazy to change. >>>> I am arguing that case insensitive software has been around for many >>>> decades, and for some people to advocate for its removal just because >>>> they don't have the brain power to come up with a proper solution for a >>>> minor glitch that affects only a small number of languages I find >>>> unacceptable. A competent programmer would fix the problem that affects >>>> the few without removing a feature that the many are used to >>> >>> and a competent programmer using PHP as programming language would not >>> define a funtion do_something() and write "Do_Something", >>> "do_Something", "DO_something" all over his codebase >> >> While that may be "uncool" or even "inconsistent" it does not cause a >> genuine problem. But you seem to be supporting a change which would be >> worse than uncool, it would be downright horrific. No human language that >> I know of allows a word to change its meaning just by changing the case >> of one or more characters > >i brought you samples of german where the meanining of the same word >changes *dramatically* - "nett zu Vögeln" versus "nett zu vögeln" which >goes from "nice to birds" to "nice to fuck" > >> and this standard behaviour was echoed in all the computer systems that I >> have used since the 1970s. The fact that I can create a function called >> do_something() and later refer to it as either Do_something(), >> do_Something() or even Do_SomeThing() may be annoying but it is >> irrelevant. Do you realise how many problems it would cause if each >> change in case pointed to a totally different function? > >only when one is so short-sighted as you act > >it's not rocket science at compile time throw a error that you are not >allowed to define foo() and Foo() in the same software which has no runtime >costs and after that you may even have less runtime costs because all the >case-insensitive handling can be skipped
None of the IDEs that I have used have enforced such a rule, neither have any languages, so it is an artificial rule invented by someone who doesn't now how to provide a proper solution. As I have said in several other posts, the vast majority of the human race has come to accept case-insensitive software, and if you can't implement it then you should step aside and make room for someone who can.
>and well, for the time of deprecation the compiler code with finally throws >errors can issue the warnings with file and line - i assure you that going >to fix that warnings takes less time than the whole discussion with you >over the last days from several people > >> Would you support anyone who proposed adding a series of functions to PHP >> core or an extension where every function used exactly the same words but >> in a different case?
>see above - just because you assume it's rocket scienece doesn't mean it is
You seem to misunderstand the term "rocket science" which means that something is so difficult that it can only be done by a highly trained individual. Something which is NOT rocket science is supposed to be so easy that anyone can do, not just a scientist. People keep telling me that switching between upper and lower case for all character sets in the universe is not 100% simple because of a small number of exceptions. So what? Identify the exceptions and write code which deals with them. If we only wrote deal to deal with the easy stuff there would be no need for highly skilled programmers as anyone could do it. -- Tony Marston
  100664
September 16, 2017 09:40 addw@phcomp.co.uk (Alain Williams)
On Sat, Sep 16, 2017 at 10:29:26AM +0100, Tony Marston wrote:

> People keep telling me that switching between upper and lower case > for all character sets in the universe is not 100% simple because of > a small number of exceptions. So what? Identify the exceptions and > write code which deals with them.
Thereby increasing the complexity of the PHP engine - which means more bugs and slower execution. It also makes it harder for the user to understand: they need to get their heads round the corner cases. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include
  100672
September 16, 2017 10:50 TonyMarston@hotmail.com ("Tony Marston")
"Alain Williams"  wrote in message 
news:20170916094055.GM8096@phcomp.co.uk...
> >On Sat, Sep 16, 2017 at 10:29:26AM +0100, Tony Marston wrote: > >> People keep telling me that switching between upper and lower case >> for all character sets in the universe is not 100% simple because of >> a small number of exceptions. So what? Identify the exceptions and >> write code which deals with them. > >Thereby increasing the complexity of the PHP engine - which means more bugs >and >slower execution. It also makes it harder for the user to understand: they >need >to get their heads round the corner cases.
There should be no need to complicate the entire PHP engine. Just fix the UNICODE exceptions so that strtoupper() and strtolower() work properly for that small number of peculiar character sets. -- Tony Marston
  100580
September 14, 2017 12:33 lester@lsces.co.uk (Lester Caine)
On 14/09/17 10:20, Tony Marston wrote:
> Then unix came along and FUBAR'd everything. Any advantages of case > sensitive systems are ALWAYS outweighed by their disadvantages.
Unix predates Windows ... the use of such breaks as having spaces in file names came from that development in addition to the line ending. The RTTY machines needed a carriage return step followed by a line feed which is why that was two steps initially. Not needed these days, but still embeded from the early days. UTF8 introduces a level of complexity and can be used used in many places in PHP, but it does seem that there is no drive these days to make the core a clean UTF8 environment. This should perhaps be addressed again for PHP8? But the additional problems that case-insensitive then introduces may mean that all case-insensitivity has to be removed at that point? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  100582
September 14, 2017 13:10 tendoaki@gmail.com (Michael Morris)
On Thu, Sep 14, 2017 at 8:33 AM, Lester Caine <lester@lsces.co.uk> wrote:

> UTF8 introduces a level of complexity and can be used used in many > places in PHP, but it does seem that there is no drive these days to > make the core a clean UTF8 environment. This should perhaps be addressed > again for PHP8? > > *Cough*, *Cough*, PHP 6, *Cough*, *Cough*.
Comedy aside, Full UTF functionality was planned for PHP 6 and ended up sinking the branch because it was way more complicated that anyone realized at first. Someone involved with the development at that time can speak to it more accurately - all I know is hearsay and conjecture.
  100587
September 14, 2017 13:32 lester@lsces.co.uk (Lester Caine)
On 14/09/17 14:10, Michael Morris wrote:
> On Thu, Sep 14, 2017 at 8:33 AM, Lester Caine <lester@lsces.co.uk> wrote: > >> UTF8 introduces a level of complexity and can be used used in many >> places in PHP, but it does seem that there is no drive these days to >> make the core a clean UTF8 environment. This should perhaps be addressed >> again for PHP8? >> > *Cough*, *Cough*, PHP 6, *Cough*, *Cough*. > > Comedy aside, Full UTF functionality was planned for PHP 6 and ended up > sinking the branch because it was way more complicated that anyone realized > at first. Someone involved with the development at that time can speak to > it more accurately - all I know is hearsay and conjecture.
My point exactly ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  100583
September 14, 2017 13:16 TonyMarston@hotmail.com ("Tony Marston")
"Lester Caine"  wrote in message 
news:20b8b6fa-ec81-eba9-d33b-b54b815e9e5d@lsces.co.uk...
> >On 14/09/17 10:20, Tony Marston wrote: >> Then unix came along and FUBAR'd everything. Any advantages of case >> sensitive systems are ALWAYS outweighed by their disadvantages. > >Unix predates Windows ...
A minor detail. Windows followed all the previous OSes which I had used in being case insensitive, which makes unix the odd one out. Besides there are far more computers running Windows than unix, so unixx should not be used as the standard.
> the use of such breaks as having spaces in >file names came from that development in addition to the line ending. >The RTTY machines needed a carriage return step followed by a line feed >which is why that was two steps initially. Not needed these days, but >still embeded from the early days.
I also saw LF and CR being used independently in a driver for a daisywheel printer in the 1970s. The fact that both CR and LF are not needed these days should have been addressed by a common solution used by all OSes, and not each OS using a different solution.
>UTF8 introduces a level of complexity and can be used used in many >places in PHP, but it does seem that there is no drive these days to >make the core a clean UTF8 environment. This should perhaps be addressed >again for PHP8?
If UTF8 solves the problem, but has yet to be properly implemented in PHP, then the PHP implementation should be addressed.
> But the additional problems that case-insensitive then >introduces may mean that all case-insensitivity has to be removed at >that point?
What additional problems? When billions of people are used to living in a case-insensitive world and the only "problems" affect an insignificantly small number in an insignificantly small number of circumstances then the only proper solution is one that solves the problem for the small number without messing it up for the far larger number. -- Tony Marston
  100589
September 14, 2017 13:38 addw@phcomp.co.uk (Alain Williams)
On Thu, Sep 14, 2017 at 02:16:47PM +0100, Tony Marston wrote:

> A minor detail. Windows followed all the previous OSes which I had > used in being case insensitive, which makes unix the odd one out. > Besides there are far more computers running Windows than unix, so > unixx should not be used as the standard.
So you want a return to the horrors of code pages in file systems ? Ie how you map lower -> upper depends on how you encode characters. Far better that that problem is taken away from the file system (which should be clean, robust and fast) and if you want case independence put it up at the application layer. I vote for making it case sensitive: simpler for the parser; the programmer rapidly learns that it should be 'TRUE' and not 'true' -- job done. This is what Javascript does. Many operating systems were case insensitive since your input terminal (eg AR33 Teletype) could only generate one case. But in those days it was simple since you only had one character set: ASCII or EBCDIC (translation of alphabetics between the 2 was easy, some others not so, eg: @"\£#).
> >But the additional problems that case-insensitive then > >introduces may mean that all case-insensitivity has to be removed at > >that point? > > What additional problems? When billions of people are used to living > in a case-insensitive world and the only "problems" affect an > insignificantly small number in an insignificantly small number of > circumstances then the only proper solution is one that solves the > problem for the small number without messing it up for the far > larger number.
That is the sort of mind-set that results in browsers accepting all sort of broken markup and making guesses on what is intended; different browsers make different guesses and render the page differently. The user then blames browser X for getting it wrong rather than the incompetent web developer who can't be bothered to check that their markup is correct. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include
  100595
September 14, 2017 15:37 francois@tekwire.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)
Le 14/09/2017 à 15:38, Alain Williams a écrit :
> I vote for making it case sensitive: simpler for the parser; the > programmer > rapidly learns that it should be 'TRUE' and not 'true' -- job done.
No need to force people to switch their code to 'TRUE'. Just supporting case-sensitive 'TRUE', 'true', and 'True' (the same for false and null) should be enough. Not supporting 'tRUE' or 'TrUe' anymore will also be a positive side effect for code readability. Regards François
  100597
September 14, 2017 15:45 pollita@php.net (Sara Golemon)
On Thu, Sep 14, 2017 at 11:37 AM, François Laupretre
<francois@tekwire.net> wrote:
> Le 14/09/2017 à 15:38, Alain Williams a écrit : >> >> I vote for making it case sensitive: simpler for the parser; the >> programmer >> rapidly learns that it should be 'TRUE' and not 'true' -- job done. > > > No need to force people to switch their code to 'TRUE'. Just supporting > case-sensitive 'TRUE', 'true', and 'True' (the same for false and null) > should be enough. Not supporting 'tRUE' or 'TrUe' anymore will also be a > positive side effect for code readability. > +0.9 this. It feels pretty simple to resolve this special-case for
case-sensitivity at any stage of the compile, but the reality is that TRUE/True/true covers 99% of uses, and a static analyzer can *trivially* find those other cases prior to an upgrade. Heck, 3 minutes with a token_get_all() script can find 'em, even produce a rewrite diff if you're so inclined. Nevermind, make that +1. The ease of auditing mixed-case uses makes supporting it in the compiler not worth the maintenance. -Sara
  100600
September 14, 2017 16:25 cmbecker69@gmx.de ("Christoph M. Becker")
On 14.09.2017 at 17:37, François Laupretre wrote:

> Le 14/09/2017 à 15:38, Alain Williams a écrit : > >> I vote for making it case sensitive: simpler for the parser; the >> programmer >> rapidly learns that it should be 'TRUE' and not 'true' -- job done. > > No need to force people to switch their code to 'TRUE'. Just supporting > case-sensitive 'TRUE', 'true', and 'True' (the same for false and null) > should be enough. Not supporting 'tRUE' or 'TrUe' anymore will also be a > positive side effect for code readability.
I'd rather not introduce a special case here. All PHP keywords are currently case-insensitive (CMIIW), so promoting true, false and null from reserved words to keywords would solve this issue: all constants are case-sensitive, all keywords are case-insensitive, the latter obviously taking precedence. And frankly, if somebody really prefers to write "TruE", why bother? This would still be far from having a chance to win a "most obfuscated code contest". -- Christoph M. Becker
  100609
September 15, 2017 08:51 TonyMarston@hotmail.com ("Tony Marston")
"Alain Williams"  wrote in message 
news:20170914133846.GQ8096@phcomp.co.uk...
> >On Thu, Sep 14, 2017 at 02:16:47PM +0100, Tony Marston wrote: > >> A minor detail. Windows followed all the previous OSes which I had >> used in being case insensitive, which makes unix the odd one out. >> Besides there are far more computers running Windows than unix, so >> unixx should not be used as the standard. > >So you want a return to the horrors of code pages in file systems ?
I never said that.
> Iike how you map lower -> upper depends on how you encode characters.
Then use a single UNICODE character set where every character has both an upper and lower case representation. Problem solved.
> Far better that that >problem is taken away from the file system (which should be clean, robust >and >fast) and if you want case independence put it up at the application layer.
You try telling that to the billions of Windows users who have been used to a case insensitive file system for decades. Not to mention all Microsoft software which is case insensitive. Try to take that away and billions of users will be baying for your blood.
>I vote for making it case sensitive: simpler for the parser; the programmer >rapidly learns that it should be 'TRUE' and not 'true' -- job done. > >This is what Javascript does.
I don't give two hoots what javascript does.
>Many operating systems were case insensitive since your input terminal (eg >AR33 >Teletype) could only generate one case. But in those days it was simple >since >you only had one character set: ASCII or EBCDIC (translation of alphabetics >between the 2 was easy, some others not so, eg: @"\£#). > >> >But the additional problems that case-insensitive then >> >introduces may mean that all case-insensitivity has to be removed at >> >that point? >> >> What additional problems? When billions of people are used to living >> in a case-insensitive world and the only "problems" affect an >> insignificantly small number in an insignificantly small number of >> circumstances then the only proper solution is one that solves the >> problem for the small number without messing it up for the far >> larger number.
>That is the sort of mind-set that results in browsers accepting all sort of >broken markup and making guesses on what is intended; different browsers >make >different guesses and render the page differently. The user then blames >browser >X for getting it wrong rather than the incompetent web developer who can't >be >bothered to check that their markup is correct.
UNICODE was supposedly invented to deal with all these problems so why doesn't it? Why is it not possible to define an uppercase and lowercase variant of the same character? If the problem lies with an incomplete implementation of UNICODE then that is the problem which should be addressed. Any programmer who says that he doesn't have the brain power to provide a proper solution and proposes instead to remove case insensitivity from the entire universe "because it is more convenient" should hang his head in shame. It is the programmer's job to make things easier and more convenient for the user, not for users to accept what is convenient for the programmers to provide. -- Tony Marston
  100613
September 15, 2017 09:17 narf@devilix.net (Andrey Andreev)
Hi,

On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston <TonyMarston@hotmail.com> wrote:
> >> Far better that that >> problem is taken away from the file system (which should be clean, robust >> and >> fast) and if you want case independence put it up at the application >> layer. > > > You try telling that to the billions of Windows users who have been used to > a case insensitive file system for decades. Not to mention all Microsoft > software which is case insensitive. Try to take that away and billions of > users will be baying for your blood. >
Billions? Do we have that statistic available? And how many of them have ever encountered case-sensitivity as a concept? Do they all manually type-in filenames that they want to open? If so, do they for some reason name their files in all upper-case, but then type in lower-case while opening? Also, are we Microsoft developers? Are we trying to change Windows? And most importantly: How do everyday Windows users have anything to do with PHP developers? Cheers, Andrey.
  100617
September 15, 2017 09:46 TonyMarston@hotmail.com ("Tony Marston")
"Andrey Andreev"  wrote in message 
news:CAPhkiZyXgxi-7vWdqA2hxni9SvycuN_pWOOM8un8mUo5qJ=0jg@mail.gmail.com...
> >Hi, > >On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston <TonyMarston@hotmail.com> >wrote: >> >>> Far better that that >>> problem is taken away from the file system (which should be clean, >>> robust >>> and >>> fast) and if you want case independence put it up at the application >>> layer. >> >> >> You try telling that to the billions of Windows users who have been used >> to >> a case insensitive file system for decades. Not to mention all Microsoft >> software which is case insensitive. Try to take that away and billions of >> users will be baying for your blood. >> > >Billions? Do we have that statistic available?
How many people in the world work with PCs running Microsoft Windows? More than those running alternatives.
>And how many of them have ever encountered case-sensitivity as a concept?
None, because they have always used case-insensitive software.
>Do they all manually type-in filenames that they want to open? If so, >do they for some reason name their files in all upper-case, but then >type in lower-case while opening?
When searching for a file in Windows it is not necessary to now what case it was created in. When searching for a word in a file it is not necessary to now what case it was created in. TRy taking that ability away from Windows users and see what reaction you get.
>Also, are we Microsoft developers? Are we trying to change Windows?
No, but you are suggesting a change from being consistent with Windows to being inconsistent.
>And most importantly: How do everyday Windows users have anything to >do with PHP developers?
Some people are also Windows users as well as PHP developers, and if those people are told that some of the software which they use is now being switched from being case-insensitive to case-sensitive just because the programmers cannot solve a small problem which only affects a small number of character sets, then those people will not be happy. Case-insensitive software has been around for decades and is regarded by many users as a feature. It that "feature" is broken in a small number of cases then a proper programmer would fix that broken feature and not advocate for its removal just because it is more convenient than developing a fix. -- Tony Marston
  100620
September 15, 2017 10:08 narf@devilix.net (Andrey Andreev)
Hi again,

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

> >Iike how you map lower -> upper depends on how you encode characters. > > Then use a single UNICODE character set where every character has > both an upper and lower case representation. Problem solved.
Not possible - see below.
> I don't give two hoots what javascript does.
Many PHP programmers also write Javascript. Avoiding gratuitous inconsistencies will help them.
> UNICODE was supposedly invented to deal with all these problems so > why doesn't it? Why is it not possible to define an uppercase and > lowercase variant of the same character?
I don't think that you understand Unicode. Case mapping is not as simple as you seem to think - even in English. For a start there are 3 cases: lower, upper & title. It then gets more complicated. I suggest that you read: http://unicode.org/faq/casemap_charprop.html -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include
  100626
September 15, 2017 14:25 TonyMarston@hotmail.com ("Tony Marston")
"Alain Williams"  wrote in message 
news:20170915093457.GI8096@phcomp.co.uk...
> >On Fri, Sep 15, 2017 at 09:51:53AM +0100, Tony Marston wrote: > >> >Iike how you map lower -> upper depends on how you encode characters. >> >> Then use a single UNICODE character set where every character has >> both an upper and lower case representation. Problem solved. > >Not possible - see below. > >> I don't give two hoots what javascript does. > >Many PHP programmers also write Javascript. Avoiding gratuitous >inconsistencies >will help them. > >> UNICODE was supposedly invented to deal with all these problems so >> why doesn't it? Why is it not possible to define an uppercase and >> lowercase variant of the same character? > >I don't think that you understand Unicode. Case mapping is not as simple as >you >seem to think - even in English. For a start there are 3 cases: lower, >upper & >title. It then gets more complicated. I suggest that you read: > >http://unicode.org/faq/casemap_charprop.html
I have read that article, and while it says that case switching may not be easy it does not say that it is impossible. While most case mappings work on a one-to-one basis it is possible to specify any one-to-any mappings as well as any additional mappings used in case folding for any exceptions. -- Tony Marston
  100549
September 12, 2017 19:43 smalyshev@gmail.com (Stanislav Malyshev)
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
  100550
September 12, 2017 19:55 pollita@php.net (Sara Golemon)
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
  100552
September 12, 2017 21:02 cmbecker69@gmx.de ("Christoph M. Becker")
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
  100592
September 14, 2017 13:53 nikita.ppv@gmail.com (Nikita Popov)
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
  100605
September 14, 2017 21:22 smalyshev@gmail.com (Stanislav Malyshev)
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
  100607
September 14, 2017 22:55 cmbecker69@gmx.de ("Christoph M. Becker")
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:
  100608
September 14, 2017 23:34 smalyshev@gmail.com (Stanislav Malyshev)
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.
> 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
  100624
September 15, 2017 13:42 cmbecker69@gmx.de ("Christoph M. Becker")
On 15.09.2017 at 01:34, Stanislav Malyshev wrote:

>> > 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
  100615
September 15, 2017 09:25 TonyMarston@hotmail.com ("Tony Marston")
""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: > > 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
  100619
September 15, 2017 10:00 lists@rhsoft.net ("lists@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
  100632
September 15, 2017 14:58 TonyMarston@hotmail.com ("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. -- Tony Marston
  100633
September 15, 2017 15:08 lists@rhsoft.net ("lists@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 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?
  100662
September 16, 2017 09:36 TonyMarston@hotmail.com ("Tony Marston")
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
  100669
September 16, 2017 09:53 lists@rhsoft.net ("lists@rhsoft.net")
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
  100671
September 16, 2017 10:45 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:b7f14ab8-feed-b3d8-293a-ac658adab0d7@rhsoft.net...
> > > >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 stated your opinion often enough as you did in the thread where you >explained us that code consistency don't matter for you - in both cases >nobody agreed
Consistency with what? Why should I change the way that I code just to be consistent with somebody else's bad decisions? Why should I have to take someone else's personal preferences and treat them as if they were cast in stone and handed down from the mountain top? -- Tony Marston
  100596
September 14, 2017 15:38 pollita@php.net (Sara Golemon)
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
  100598
September 14, 2017 16:02 levim@php.net (Levi Morrison)
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.
  100602
September 14, 2017 18:27 pollita@php.net (Sara Golemon)
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
  100676
September 16, 2017 15:04 zeev@zend.com (Zeev Suraski)
> -----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
  100677
September 16, 2017 15:24 levim@php.net (Levi Morrison)
> 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.
  100681
September 16, 2017 16:37 zeev@zend.com (Zeev Suraski)
> -----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
  100682
September 16, 2017 18:09 pollita@php.net (Sara Golemon)
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
  100685
September 16, 2017 19:33 smalyshev@gmail.com (Stanislav Malyshev)
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
  100684
September 16, 2017 19:31 smalyshev@gmail.com (Stanislav Malyshev)
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
  100686
September 16, 2017 21:23 cmbecker69@gmx.de ("Christoph M. Becker")
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