## Deprecate and remove case-insensitive constants?

September 12, 2017 12:02
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
September 12, 2017 12:52
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
September 12, 2017 13:04
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
September 12, 2017 14:04
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()

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
September 16, 2017 03:22
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
September 12, 2017 14:52
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
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.
September 12, 2017 14:55
> 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
> 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.
September 12, 2017 16:17
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]
September 12, 2017 16:45
> 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.
September 12, 2017 17:59
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] September 12, 2017 20:35 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...
September 13, 2017 13:48
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] September 12, 2017 21:32 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 September 12, 2017 12:53 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 September 12, 2017 17:05 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 September 13, 2017 08:59 "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 September 13, 2017 13:15 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 > > September 13, 2017 14:06 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] September 13, 2017 15:50 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] > September 13, 2017 16:12 "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 September 13, 2017 13:59 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 September 13, 2017 15:16 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 September 13, 2017 16:03 "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 September 14, 2017 09:23 ""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 September 14, 2017 12:02 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] September 16, 2017 08:57 "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 September 13, 2017 17:24 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 September 14, 2017 09:20 "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 September 14, 2017 09:40 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 September 14, 2017 12:59 "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 September 14, 2017 13:27 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 September 14, 2017 13:36 ""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 September 14, 2017 13:46 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  September 15, 2017 09:02 "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 September 15, 2017 12:44 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 September 15, 2017 14:54 "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 September 14, 2017 13:27 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] September 14, 2017 13:48 "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 September 14, 2017 13:55 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  September 15, 2017 09:04 "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 September 14, 2017 14:05 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 September 15, 2017 09:12 "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 September 15, 2017 09:21 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  September 15, 2017 14:15 "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 September 15, 2017 14:27 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! September 16, 2017 09:16 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 September 16, 2017 09:54 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 September 16, 2017 10:56 ""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 September 18, 2017 04:38 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. September 18, 2017 09:40 "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 September 18, 2017 10:40 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
<https://www.w3.org/International/wiki/Case_folding>.

--
Christoph M. Becker
September 19, 2017 09:24
""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 September 19, 2017 09:35 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 September 20, 2017 09:30 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 September 20, 2017 10:07 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.
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
September 20, 2017 10:07
Am 20.09.2017 um 11:30 schrieb Tony Marston:
>>
>>
>>
>> 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
September 22, 2017 08:21
wrote in message news:064eafcb-e42f-cfeb-76f1-e2c5aec0ea27@rhsoft.net...
>
>
>
>Am 20.09.2017 um 11:30 schrieb Tony Marston:
>>>
>>>
>>>
>>> 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

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
September 22, 2017 10:37
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
>
> 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....
September 24, 2017 09:36
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
>>
>> 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
September 24, 2017 10:05
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 
September 24, 2017 10:52
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
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
September 24, 2017 12:07
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 
September 25, 2017 09:30
"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
September 24, 2017 10:07
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
>>>
>>> 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
September 25, 2017 09:41
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
September 25, 2017 09:49
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

> 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?
September 25, 2017 11:04
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]
September 26, 2017 09:00
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
>
>
>> 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
September 24, 2017 15:44
> 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.

-Sara
September 20, 2017 10:49
>
> 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:

>
>>
>>
>>
>> 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
>
>
September 15, 2017 09:53
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.
September 15, 2017 14:38
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
September 15, 2017 14:48
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
September 16, 2017 09:29
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
September 16, 2017 09:40
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 
September 16, 2017 10:50
"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
September 14, 2017 12:33
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
September 14, 2017 13:10
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.
September 14, 2017 13:32
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
September 14, 2017 13:16
"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
September 14, 2017 13:38
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 
September 14, 2017 15:37
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
September 14, 2017 15:45
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
September 14, 2017 16:25
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
September 15, 2017 08:51
"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
September 15, 2017 09:17
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.
September 15, 2017 09:46
"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
September 15, 2017 10:08
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.
>

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

comparisons, and talk about *constants in PHP*.

Cheers,
Andrey.
September 15, 2017 11:13
"Andrey Andreev"  wrote in message
>
>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.
>>
>

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.
>
>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
September 15, 2017 12:31
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
September 15, 2017 14:48
"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
September 15, 2017 09:34
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 
September 15, 2017 14:25
"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
September 12, 2017 19:43
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
September 12, 2017 19:55
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
September 12, 2017 21:02
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
September 14, 2017 13:53
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
September 14, 2017 21:22
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
September 14, 2017 22:55
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:


September 14, 2017 23:34
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
September 15, 2017 13:42
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
September 15, 2017 09:25
""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
>
>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
September 15, 2017 10:00
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
September 15, 2017 14:58
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
September 15, 2017 15:08
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?
September 16, 2017 09:36
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
>
>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
September 16, 2017 09:53
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
September 16, 2017 10:45
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
September 14, 2017 15:38
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
September 14, 2017 16:02
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.
September 14, 2017 18:27
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
September 16, 2017 15:04
> -----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
September 16, 2017 15:24
> 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.
September 16, 2017 16:37
> -----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
> 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
September 16, 2017 18:09
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

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

-Sara
September 16, 2017 19:33
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

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
September 16, 2017 19:31
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
September 16, 2017 21:23
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