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
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 aconstdeclaration.
However,define()allows to passTRUEas 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_DEPRECATEDwhenever the third
argument todefine()isTRUEin 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
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
I don't think we can do that. Consider, for instance, ext/gd where all
functions are actually in lower case, but I've seen a lot of code
written in pascal or camel case to make the functions better readable, e.g.
imageCreateFromJpeg()vs.imagecreatefromjpeg()
It's pretty easy to imagine that if we had function autoloading,
creating an optional small backwards compatibility shim/library to
work around that problem would be pretty easy.
It's also the type of error that would be easy to add a deprecation
warning to in a late 7.x branch.
cheers
Dan
Hi Christoph,
On Tue, Sep 12, 2017 at 10:04 PM, Christoph M. Becker cmbecker69@gmx.de
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
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 aconstdeclaration.
However,define()allows to passTRUEas 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_DEPRECATEDwhenever the third
argument todefine()isTRUEin 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
--
By itself this change provides little value. If it was done in
connection with other features such as merging symbol tables then we
can actually gain some significant improvements:
array_map(sum2, $input1, $input2);
Currently that requires sum2 to be a constant. To get the correct
behavior we currently need to do:
array_map('fully\qualified\namespace\sum2', $input1, $input2);
This is not just convenience; it provides safety to refactoring and
general code analysis tools. Maintenance is a crucial aspect of large
code bases and being able to move away from stringly-typed things is a
significant improvement. It's also a step towards general autoloading
instead of just class/trait/interface autoloading; however this would
require further changes.
I believe these improvements would be worth it and do understand it is
a large backwards compatibility break. Given sufficient time and
tooling to prepare I think PHP would be markedly better in the
long-run for these two changes. However, if we change only the case
sensitivity of constants we gain little value for our BC break.
By itself this change provides little value. If it was done in
connection with other features such as merging symbol tables then we
can actually gain some significant improvements:array_map(sum2, $input1, $input2);Currently that requires
sum2to be a constant. To get the correct
behavior we currently need to do:array_map('fully\qualified\namespace\sum2', $input1, $input2);
After rewriting my reply I noticed this sentence doesn't quite make sense:
This is not just convenience; it provides safety to refactoring and
general code analysis tools.
Instead I meant that using the string is not just inconvenient; it
also prevents fully-safe code refactoring and analysis.
Maintenance is a crucial aspect of large
code bases and being able to move away from stringly-typed things is a
significant improvement. It's also a step towards general autoloading
instead of just class/trait/interface autoloading; however this would
require further changes.I believe these improvements would be worth it and do understand it is
a large backwards compatibility break. Given sufficient time and
tooling to prepare I think PHP would be markedly better in the
long-run for these two changes. However, if we change only the case
sensitivity of constants we gain little value for our BC break.
array_map(sum2, $input1, $input2);
Currently that requires
sum2to 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]
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
sum2to 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.
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]
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...
Regards,
On Tue, Sep 12, 2017 at 11:59 AM, Rowan Collins
rowan.collins@gmail.com wrote:If we want function and class references, they should have their
own,
unambiguous, syntax.I stand by this assertion. Consider the following statement:
$foo = bar;
Even if "bar" cannot simultaneously be the name of a function, a
class, and a constant, it can still potentially be any of the three,
from the point of view of the compiler.If it's known, it's known, and it can proceed with that type. If it's
not known then autoload and proceed like normal. I fail to see how
this is an issue, and in fact, see it as a significant improvement
to our current situation...
If the symbol tables had always been unified, I guess you could think of a function name as a constant whose value happened to be of type IS_FUNC - like how in JS "function foo() {}" and "var foo = function{}" are very nearly interchangeable. But it feels like retrofitting that onto the existing language would be messy.
For instance, an autoloader would have to be given a token name, with no context of whether it's expected to be a class, function, or constant. (Of course we'd have to solve the dilemma of how global function fallback/shadowing should interact with autoloading first.) Users would have to learn this concept of an untyped token, because the error message they'd get if it wasn't defined could no longer say "undefined constant".
Then there's all the existing support for string-based callables. I can't actually think of any cases that are unresolvable, but there's some odd implications:
function foo() { echo 'Hello, world!'; }
const bar='foo';
$fn = bar;
$fn(); // already works
bar(); // would this work? if not, why not, since it's no longer ambiguous?
const baz='bar';
$fn2 = baz;
$fn2(); // in which case, would this also work?
baz(); // and then what about this?
I feel like this could lead to confusion either way, and just increase the complexity for both human and machine analysis.
Then there's other symbol tables that would need to be unified - we'd want $foo->bar be able to grant a method reference, and Foo::bar a static method reference. Just how much code is it worth breaking to allow this syntax?
It feels a lot cleaner to say "function and class references are a new concept, and you'll know when you're using them because they look like this". Something like "SomeClass::classref", "some_func::funcref", "SomeClass::someStaticMethod::funcref", "$some_object->someMethod::funcref".
Rowan Collins
[IMSoP]
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_DEPRECATEDwhenever the third
argument todefine()isTRUEin PHP 7.3, and to remove this parameter
altogether in PHP 8. Most likely some further simplification in the
engine could be done then as well.[…] However, if we change only the case
sensitivity of constants we gain little value for our BC break.
I have not suggested to change the case sensivity of constants, but
rather to settle on a common case – since const constants are always
case-sensitive, it appears that this should be so for define'd
constants. This would make code as the following to work as expected:
a.php
<?php
const FOO = 'bar';
?>
b.php
<?php
define('FOO', 'baz', 1); // => true
echo FOO; // => bar - WFT?
?>
And it obviously would fix a bug. IMHO, that is sufficient gain for a
presumably moderate BC break.
Please note, that I do not want to pursue a discussion regarding
changing all constants to be case-sensitive or all functions and class
names to be case-insensitive. Of course, it is fine to discuss it, but
it is clearly out of scope for what I'm trying to improve (in my
opinion) here, which is more in the "a bird in the hand is worth two in
the bush" corner.
If it will be decided that all constant identifiers should be
case-insensitive, I'd be fine with it (not happy, though). Probably, I
should reword the RFC to reflect that it is actually about deprecation
and removal of the third parameter of define() (plus preventing any
extension to register constants which do not conform to the "default"
casing). In short: don't have two kinds of constants wrt. spelling
(true, false, null are not covered, since they are special anyway and
could be promoted to keywords).
--
Christoph M. Becker
--
Christoph
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 aconstdeclaration.
However,define()allows to passTRUEas 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_DEPRECATEDwhenever the third
argument todefine()isTRUEin 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
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
"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 preferconstoverdefineanyway. 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
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
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]
On Wed, Sep 13, 2017 at 8:06 AM, Rowan Collins rowan.collins@gmail.com
wrote:
On 13 September 2017 14:15:43 BST, Ryan Pallas derokorian@gmail.com
wrote:I must be missing something, there is no autoloader shipped with PHP.
Just to be pedantically correct, there actually is an implementation
shipped, see http://php.net/spl_autoload It's even the default if you
don't pass your own function to spl_autoload_register.
Almost 2 decades in PHP, and still so much I don't know haha. I will point
out though, that according to a comment [1] it does not replace the
underscores with slashes as mentioned, and I see no where in the code [2]
that it does either.
[1] http://php.net/manual/en/function.spl-autoload.php#98762
[2] https://github.com/php/php-src/blob/master/ext/spl/php_spl.c#L306
Nonetheless, you are quite right that Tony's complaint is nonsensical,
because he could implement whatever autoloader suited his directory
structure, if he wanted to - even a case insensitive one.It is true that autoloading isn't mandatory, but it's also a complete
straw man, because Sara already made the same point herself:I don't feel as though that's true of ...
projects where autoloaders
aren't used (not a small number).Regards,
--
Rowan Collins
[IMSoP]
"Ryan Pallas" 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
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
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
"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 sameias it does in English but a different
i that is not considered equal. Thus classes such asIteratorare
not found in the Turkish locales. Note that this bug was fixed, and
then there was a regression that lasted until PHP 5.5.There are other case insensitivity bugs but this Turkish one is the
poster child and if you search around you can find many examples of
it.Case sensitivity is thus a correctness issue and not a "cool"ness,
personal preference, performance, or some other type of issue. I argue
correctness and maintenance issues are the most important and thus if
we change sensitivity of any type of symbol it should go in the
direction of being case sensitive. Someone can disagree on what they
value but people who think case insensitivity is not a correctness
issue "are deluding themselves".Levi Morrison
I'm sorry, but errors in translation from one character set to another are
insignificant when compared with the much larger problem of the same word
having diferent meanings depending on case. In the English language "info"
is the same as "Info" is the same as "INFO" is the same as "iNFO" is the
same as "iNfO" and so on. If the problem is that an English word cannot be
recognised as the same word regardless of case when switching to a
non-English character set then the issue is with switching to a non-English
character set.
Introducing case sensitivity just for this minor bug would create more
issues than it would solve, so this bug should be solved using a different
technique .
--
Tony Marston
""Tony Marston"" 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 sameias it does in English but a different
i that is not considered equal. Thus classes such asIteratorare
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
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]
"Rowan Collins" wrote in message
news:A7FFCE81-74E5-47D0-9EBF-9BDC90E2E957@gmail.com...
On 14 September 2017 10:23:48 BST, Tony Marston
Would this problem disappear by using UTF8 instead of the Turkish
character
set? If so then ten no other solution would be required.No, the problem has nothing to do with character sets, but with the actual
alphabet that humans in Turkey use, which doesn't follow the same rules as
the alphabet that American humans use.Unicode (the standard, not the character set or any of its encodings) has
an algorithm / lookup table for "case folding", because "convert everything
to lower case" is not a reliable way to produce case insensitive
comparisons. Using that correctly world presumably solve this particular
problem.The bottom line is that case sensitive comparisons are easier than case
insensitive ones.
A programmer's job is to write software which makes life easier for his
users, not to remove features which his users are used to just because it is
"more convenient" for him.
While the vast majority of characters in any character set have a one-to-one
mapping between upper and lower case, there are exceptions. I have been
writing software for several decades, and I have come to know the 80-20 rule
which states that 80% of the code is for "normal" circumstances while 20% is
for the exceptions, yet coding for the "normal" circumstances takes 20% of
the effort while the exceptions require 80%. It is the programmer's job to
deal with these exceptions, so to say that it's not going to be done because
it is not easy is a very poor excuse.
--
Tony Marston
"Sara Golemon" 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 preferconstoverdefineanyway. 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
"Sara Golemon" wrote in message
news:CAESVnVp6OKB64WuO9iKEP=L9-QrrFjS+kcoeKYKULRUff-RitQ@mail.gmail.com...
<snip> >> People who think that case sensitive software is cool are deluding >> themselves. When I started working on mainframe computers (UNIVAC and >> IBM) >> in the early 1970s everything was case-insensitive. This was only changed >> by >> people who did not understand the ramifications of their choice. >> >Yeah, decades of C/C++/Java developers are so dumb, like... fer reals. >Friggin' script kiddies, the lot of 'em. > >-SaraOn Wed, Sep 13, 2017 at 8:59 AM, Tony Marston TonyMarston@hotmail.com
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. 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
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
"Daniel Morris" wrote in message
news:1505382004.4078127.1105791680.3A06C2FA@webmail.messagingengine.com...
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
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
""Christoph M. Becker"" wrote in message
news:98ab178e-b999-7e36-5ff5-7b8c28fe0dd4@gmx.de...
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
""Christoph M. Becker"" wrote in message
news:98ab178e-b999-7e36-5ff5-7b8c28fe0dd4@gmx.de...Introducing case sensitivity into what is mostly a case-insensitive
world just for the convenience of a few programmers I do not consider to
be acceptable. It would cause more problems for far more people than the
insignificant few who insist on using obscure character sets. Why should
the English-speaking world be forced to suffer just because some minor
languages cannot handle case folding?This is not about an "insignificant few who insist on using obscure
character sets", but rather about a language spoken by millions of
people which has to "I" characters, namely dotted and dotless "I".
Rather consistently, the dotless "I"'s lower-case variant is "i", and
the dotted "I"'s lower-case variant is "i". There you go.The number of people in the world who use character sets which do
not have this problem far outnumber those who use character sets
which do have this problem. People without this problem far
outnumber the others, so it would not be a good idea to
inconvenience the many just to satisfy the few.
Translation: I do not use these character sets, those who do are not important.
PHP (& File systems) are best staying away from things like that. Not attempting
case folding, and similar, makes it simpler, faster & more robust (not worrying
about what sort of 'i' to convert to). It only helps those who do not know what
the SHIFT key is for.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
"Alain Williams" wrote in message
news:20170914134603.GS8096@phcomp.co.uk...
""Christoph M. Becker"" wrote in message
news:98ab178e-b999-7e36-5ff5-7b8c28fe0dd4@gmx.de...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
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
"Lester Caine" wrote in message
news:55603872-e832-65ea-25b6-48e01074a4c7@lsces.co.uk...
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
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]
"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
"Rowan Collins" wrote in message
news:7394E3CE-B05A-474E-8AB5-A651FDD35232@gmail.com...On 14 September 2017 13:59:20 BST, Tony Marston
TonyMarston@hotmail.com wrote:Why should the
English-speaking world be forced to suffer just because some minor
languages
cannot handle case folding?Have you any idea how arrogant this sounds? Why should "the
English-speaking world" get to make up the rules? What criteria
make something "a minor language"? Who gave you the right to make
such lofty pronouncements?Because the English-speaking world invented both computers and the
languages used to program them.
The light bulb was invented by an English man (Joseph Swan), the television by a
Scott (John Logie Baird); so should the Brits and Scots be the ones that define
light bulb and TV standards to suit their convenience ?
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
"Alain Williams" wrote in message
news:20170914135519.GW8096@phcomp.co.uk...
"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
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.
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
"Daniel Morris" wrote in message
news:1505397937.4137791.1106049000.16B8878B@webmail.messagingengine.com...
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.
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
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.
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 toand 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.netSeriously, 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
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 toand 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 codebaseWhile 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
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 toand 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 codebaseWhile 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 charactersi 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 peopleWould 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
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
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.
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
"Lester Caine" wrote in message
news:20b8b6fa-ec81-eba9-d33b-b54b815e9e5d@lsces.co.uk...
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
A minor detail. Windows followed all the previous OSes which I had
used in being case insensitive, which makes unix the odd one out.
Besides there are far more computers running Windows than unix, so
unixx should not be used as the standard.
So you want a return to the horrors of code pages in file systems ? Ie how you
map lower -> upper depends on how you encode characters. Far better that that
problem is taken away from the file system (which should be clean, robust and
fast) and if you want case independence put it up at the application layer.
I vote for making it case sensitive: simpler for the parser; the programmer
rapidly learns that it should be 'TRUE' and not 'true' -- job done.
This is what Javascript does.
Many operating systems were case insensitive since your input terminal (eg AR33
Teletype) could only generate one case. But in those days it was simple since
you only had one character set: ASCII or EBCDIC (translation of alphabetics
between the 2 was easy, some others not so, eg: @"\£#).
But the additional problems that case-insensitive then
introduces may mean that all case-insensitivity has to be removed at
that point?What additional problems? When billions of people are used to living
in a case-insensitive world and the only "problems" affect an
insignificantly small number in an insignificantly small number of
circumstances then the only proper solution is one that solves the
problem for the small number without messing it up for the far
larger number.
That is the sort of mind-set that results in browsers accepting all sort of
broken markup and making guesses on what is intended; different browsers make
different guesses and render the page differently. The user then blames browser
X for getting it wrong rather than the incompetent web developer who can't be
bothered to check that their markup is correct.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
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
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
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
"Alain Williams" wrote in message
news:20170914133846.GQ8096@phcomp.co.uk...
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
Hi,
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.
"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
Hi again,
"Andrey Andreev" wrote in message
news:CAPhkiZyXgxi-7vWdqA2hxni9SvycuN_pWOOM8un8mUo5qJ=0jg@mail.gmail.com...Hi,
On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston TonyMarston@hotmail.com
wrote:Far better that that
problem is taken away from the file system (which should be clean,
robust
and
fast) and if you want case independence put it up at the application
layer.You try telling that to the billions of Windows users who have been used
to
a case insensitive file system for decades. Not to mention all Microsoft
software which is case insensitive. Try to take that away and billions of
users will be baying for your blood.Billions? Do we have that statistic available?
How many people in the world work with PCs running Microsoft Windows? More
than those running alternatives.
So you admit that you just made up the number?
And how many of them have ever encountered case-sensitivity as a concept?
None, because they have always used case-insensitive software.
And that will not change, regardless of how PHP constants work. Thus,
re-inforcing my point - that you're completely off-topic.
Do they all manually type-in filenames that they want to open? If so,
do they for some reason name their files in all upper-case, but then
type in lower-case while opening?When searching for a file in Windows it is not necessary to now what case it
was created in. When searching for a word in a file it is not necessary to
now what case it was created in. TRy taking that ability away from Windows
users and see what reaction you get.
- Search is a feature that goes way beyond case-sensitivity, and that
was not what I was (rhetorically) asking. - Unless Windows users search for filenames matching constants
declared in PHP code, this is irrelevant.
Also, are we Microsoft developers? Are we trying to change Windows?
No, but you are suggesting a change from being consistent with Windows to
being inconsistent.
It happens to be consistent; nobody has ever cared about whether it is or not.
And I am not suggesting anything. I am simply pointing out the
ridiculous false-equivalences you're making.
And most importantly: How do everyday Windows users have anything to
do with PHP developers?Some people are also Windows users as well as PHP developers, and if those
people are told that some of the software which they use is now being
switched from being case-insensitive to case-sensitive just because the
programmers cannot solve a small problem which only affects a small number
of character sets, then those people will not be happy. Case-insensitive
software has been around for decades and is regarded by many users as a
feature. It that "feature" is broken in a small number of cases then a
proper programmer would fix that broken feature and not advocate for its
removal just because it is more convenient than developing a fix.
You do realize you just went from comparing "billions" and how
supposedly an overwhelming majority would be upset, to "some people".
And even within that intersection of audiences, you would never be
able to convince anybody here, that for some reason John Doe would
declare a constant as FOO, but then use it as Foo.
I believe I've made my point. Please stop with the non-sense
comparisons, and talk about constants in PHP.
Cheers,
Andrey.
"Andrey Andreev" wrote in message
news:CAPhkiZxdVwiEDOW9XZfcADV+o1UC=SG_pc2Nw7NqU1W_gV8bNg@mail.gmail.com...
Hi again,
On Fri, Sep 15, 2017 at 12:46 PM, Tony Marston TonyMarston@hotmail.com
wrote:"Andrey Andreev" wrote in message
news:CAPhkiZyXgxi-7vWdqA2hxni9SvycuN_pWOOM8un8mUo5qJ=0jg@mail.gmail.com...Hi,
On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston TonyMarston@hotmail.com
wrote:Far better that that
problem is taken away from the file system (which should be clean,
robust
and
fast) and if you want case independence put it up at the application
layer.You try telling that to the billions of Windows users who have been
used
to
a case insensitive file system for decades. Not to mention all
Microsoft
software which is case insensitive. Try to take that away and billions
of
users will be baying for your blood.Billions? Do we have that statistic available?
How many people in the world work with PCs running Microsoft Windows?
More
than those running alternatives.So you admit that you just made up the number?
Can you show me any statistics which prove otherwise?
And how many of them have ever encountered case-sensitivity as a
concept?None, because they have always used case-insensitive software.
And that will not change, regardless of how PHP constants work. Thus,
re-inforcing my point - that you're completely off-topic.Do they all manually type-in filenames that they want to open? If so,
do they for some reason name their files in all upper-case, but then
type in lower-case while opening?When searching for a file in Windows it is not necessary to now what case
it
was created in. When searching for a word in a file it is not necessary
to
now what case it was created in. TRy taking that ability away from
Windows
users and see what reaction you get.
- Search is a feature that goes way beyond case-sensitivity, and that
was not what I was (rhetorically) asking.- Unless Windows users search for filenames matching constants
declared in PHP code, this is irrelevant.Also, are we Microsoft developers? Are we trying to change Windows?
No, but you are suggesting a change from being consistent with Windows to
being inconsistent.It happens to be consistent; nobody has ever cared about whether it is or
not.
And I am not suggesting anything. I am simply pointing out the
ridiculous false-equivalences you're making.And most importantly: How do everyday Windows users have anything to
do with PHP developers?Some people are also Windows users as well as PHP developers, and if
those
people are told that some of the software which they use is now being
switched from being case-insensitive to case-sensitive just because the
programmers cannot solve a small problem which only affects a small
number
of character sets, then those people will not be happy. Case-insensitive
software has been around for decades and is regarded by many users as a
feature. It that "feature" is broken in a small number of cases then a
proper programmer would fix that broken feature and not advocate for its
removal just because it is more convenient than developing a fix.You do realize you just went from comparing "billions" and how
supposedly an overwhelming majority would be upset, to "some people".
And even within that intersection of audiences, you would never be
able to convince anybody here, that for some reason John Doe would
declare a constant as FOO, but then use it as Foo.I believe I've made my point. Please stop with the non-sense
comparisons, and talk about constants in PHP.
You may think that this issue is limited to constants but others do not.
Someone (not me) said that if constants were to be made case sensitive then
the rest of the language should follow suit "just to be consistent". Someone
else (not me) pointed to a bug regarding case switching when using the
Turkish character set. It was suggested that one way to resolve this issue
would be to avoid case switching altogether by making everything case
sensitive.
I suggest you look at Levi Morrison's post dated 14/09/2017 @ 17:02 which
said:
"For what it is worth the Turkish locale issue is on-topic. If we have case
sensitivity and case insensitivity simultaneously in constants and we decide
to drop one then the locale issue points towards dropping case
insensitivity."
My argument is that far too many people have become used to case insensitive
software, and to remove this "feature" for no other reason than the
programmers involved would find it "more convenient" to remove the feature
altogether rather than make the effort in implementing a proper solution
would go down like a ton of bricks with all those users.
--
Tony Marston
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
"Lester Caine" wrote in message
news:d97cd2e5-bd5b-4c9f-2c20-107560d5a2e5@lsces.co.uk...
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
Iike how you map lower -> upper depends on how you encode characters.
Then use a single UNICODE character set where every character has
both an upper and lower case representation. Problem solved.
Not possible - see below.
I don't give two hoots what javascript does.
Many PHP programmers also write Javascript. Avoiding gratuitous inconsistencies
will help them.
UNICODE was supposedly invented to deal with all these problems so
why doesn't it? Why is it not possible to define an uppercase and
lowercase variant of the same character?
I don't think that you understand Unicode. Case mapping is not as simple as you
seem to think - even in English. For a start there are 3 cases: lower, upper &
title. It then gets more complicated. I suggest that you read:
http://unicode.org/faq/casemap_charprop.html
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
"Alain Williams" wrote in message
news:20170915093457.GI8096@phcomp.co.uk...
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:
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
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
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
TRUEvs. 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
I'm worried about
TRUEvs. 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
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 aconstdeclaration.
However,define()allows to passTRUEas 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_DEPRECATEDwhenever the third
argument todefine()isTRUEin 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
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
[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 languageIf we support all case-insensitive constants that are predefined (not
sure if any exts do that but we have to support those too if they do)
then I don't see a big problem in phasing-out user-defined ones.
It seems to me that this would miss the point, namely to introduce some
consistency, and to be able to
[Nikita continued]
reduce implementation complexity on our side and resolve some bugs
that are infeasible to fix otherwise.
All programming languages that I know of are either case-sensitive or
case-insensitive. PHP is the sole execption (CMIIW) – and the potential
cognitive overhead during programming is hard to justify. Constants are
the icing on the cake: they can be either case-insensitive or
case-sensitive at the discression of the dev defining the constant.
Using an extension which defines case-insensitive constants might raise
the following issue:
<?php
define('FOO', true, true); // public const in ext; transcript from C
const FOO = false; // in global app code
Why doesn't that fail? How am I supposed to write the extension
constant afterwards? Ah, yes, foo, of course! The PHP manual
explains that quite clearly, so there must be a bug in my IDE and the
docs of the extension. Oh, it's home time – I'm going to enjoy a nice
evening reading Brainf*ck code… ;)
FTR: there are 2811 occurances of REGISTER_\w+_CONSTANT in current
php-src master, all of which use CONST_CS. phpinternalsbook.com
mentions succinctly:
| The flags are mixed OR operation between CONST_CS (case-sensitive
| constant, what we want), […]
I completely fail to see why we should retain the possibility to define
case-insensitive constants in extensions. Deprecate that for PHP 7.3.0
(which is more than a year away) and remove in PHP 8.0.0 (which might be
several years away) seems to be acceptable. IMHO we should strive to
remove accidental complexity as soon as possible (and clearly, this is
not essential complexity).
--
Christoph M. Becker
Hi!
It seems to me that this would miss the point, namely to introduce some
consistency, and to be able to
If working code would be broken, nobody needs "consistency". I've built
tons of software, and never ever any single client asked me "but do you
have 'constistency'? Surely, I'm not against that warm fuzzy feeling
that some call "consistency", but not at the expense of breaking working
code.
All programming languages that I know of are either case-sensitive or
case-insensitive. PHP is the sole execption (CMIIW) – and the potential
cognitive overhead during programming is hard to justify. Constants are
Would be very good argument if we were designing a new language called
"PHP". Unfortunately, we're about 20 years late to that. When we design
the next one, we'd be sure to take it into the account. For this one,
not breaking people's working code is IMO a much bigger and more useful
concern.
<?php
define('FOO', true, true); // public const in ext; transcript from C
const FOO = false; // in global app codeWhy 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
<?php
define('FOO', true, true); // public const in ext; transcript from C
const FOO = false; // in global app codeWhy 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
""Christoph M. Becker"" wrote in message
news:320b3863-e36b-2ed4-543b-fcbd433b1c56@gmx.de...
[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
languageIf we support all case-insensitive constants that are predefined (not
sure if any exts do that but we have to support those too if they do)
then I don't see a big problem in phasing-out user-defined ones.It seems to me that this would miss the point, namely to introduce some
consistency, and to be able to[Nikita continued]
reduce implementation complexity on our side and resolve some bugs
that are infeasible to fix otherwise.All programming languages that I know of are either case-sensitive or
case-insensitive.
You are missing a third option - Microsoft languages are case-preserving.
This is where the IDE ensures that every use of a word is automatically
switched to the case used in its original definition. This makes it
impossible to use the same word with a different case.
PHP is the sole execption (CMIIW) – and the potential
cognitive overhead during programming is hard to justify. Constants are
the icing on the cake: they can be either case-insensitive or
case-sensitive at the discression of the dev defining the constant.
Using an extension which defines case-insensitive constants might raise
the following issue:<?php
define('FOO', true, true); // public const in ext; transcript from C
const FOO = false; // in global app codeWhy doesn't that fail? How am I supposed to write the extension
constant afterwards? Ah, yes,foo, of course! The PHP manual
explains that quite clearly, so there must be a bug in my IDE and the
docs of the extension. Oh, it's home time – I'm going to enjoy a nice
evening reading Brainf*ck code… ;)FTR: there are 2811 occurances of REGISTER_\w+_CONSTANT in current
php-src master, all of which use CONST_CS. phpinternalsbook.com
mentions succinctly:| The flags are mixed OR operation between CONST_CS (case-sensitive
| constant, what we want), […]I completely fail to see why we should retain the possibility to define
case-insensitive constants in extensions. Deprecate that for PHP 7.3.0
(which is more than a year away) and remove in PHP 8.0.0 (which might be
several years away) seems to be acceptable. IMHO we should strive to
remove accidental complexity as soon as possible (and clearly, this is
not essential complexity).
Although the PHP manual says that constants are case-insensitive, it also
says that by convention all constants are uppercase. I have been following
that convention, so a change to make constants case sensitive instead of
insensitive would not bother me. In fact it would not bother me if
user-defined constants could only ever be in upper case as that would remove
any possible confusion between 'foo' and 'Foo'.
--
Tony Marston
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
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
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
morningHow 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?
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 morningHow many IDEs out there for PHP? What percentage of them support case
preserving? Zend Studio didn't when I used it. PHPEd doesn'ti need to see one which don't make autocompletion with preserved case and
if you don't use it because you like typos in general your fault
You are avoiding the question. You state that dealing with this situation
should be done within the IDE, so my question is how any PHP IDEs actually
support this feature?
If your answer to this question is another question - how any don't support
this feature? - then my answer is "none of them". Unless you can prove
otherwise, of course.
again: it's no rocket science to throw at compile time deprecation warnings
years before a final change is planned and so for sloppy legacy code you
hav enot more to do than read your error logsafter 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
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
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
Usually constant identifiers are treated case-sensitive in PHP. This is
always the case for constants defined via aconstdeclaration.
However,define()allows to passTRUEas 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
Usually constant identifiers are treated case-sensitive in PHP. This is
always the case for constants defined via aconstdeclaration.
However,define()allows to passTRUEas 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.
Usually constant identifiers are treated case-sensitive in PHP. This is
always the case for constants defined via aconstdeclaration.
However,define()allows to passTRUEas 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.
-Sara
-----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 aconstdeclaration.
However,define()allows to passTRUEas 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
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.
-
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. -
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.
-----Original Message-----
From: morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] On Behalf
Of Levi Morrison
Sent: Saturday, September 16, 2017 6:25 PM
To: Zeev Suraski zeev@zend.com
Cc: Christoph M. Becker cmbecker69@gmx.de; internals@lists.php.net
Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants?First, in the example referenced above, arguably, making all constants case
insensitive would in fact be the better solution - as you likely don't want both
sOmE_CoNsT and SOME_CONST, or more reaslitically - Some_Const and
SOME_CONST to both exist in your app - a situation case sensitive constants
would happily let you do. That said, I think the scenario of having two
define()'s, both define the same constant with different casing is such an
edge case we really shouldn't put too much emphasis on it.This argument holds no water in my eyes.
- 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.
- 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
arguably, making all constants case insensitive
would in fact be the better solution
If they were truly case-insensitive, I might agree. However, as I've
mentioned but will reiterate, they're not. They're ASCII case
insensitive, and that's a long cry from real case-insensitivity. PHP
6 was planning to make case-insensitivity real but obviously that's
dead and buried.
This is ugly, but if I'm playing devil's advocate, it is consistent
with the rest of the core runtime.
-Sara
Hi!
If they were truly case-insensitive, I might agree. However, as I've
mentioned but will reiterate, they're not. They're ASCII case
insensitive, and that's a long cry from real case-insensitivity. PHP
6 was planning to make case-insensitivity real but obviously that's
dead and buried.
Should we really go there then? Full Unicode support for these things is
probably not going to happen, and I'd argue not many people actually
need it. Like it or not, it is not super-common to write PHP function
names or constant names in Russian, Farsi or hiragana. It demoes nice,
but I'm not sure that is a primary feature people would seek.
This is ugly, but if I'm playing devil's advocate, it is consistent
with the rest of the core runtime.
Frankly, I'd be fine with either - provided that we don't have more than
one kind (i.e. if we allow case-insensitive constants, no defining both
FOO and Foo).
But for cases-sensitivity I am worried about BC impact. We do have a
bunch of CI constants in extensions, including such widely used modules
as mcrypt. I'm not sure people use it in different cases, but hard to
really know... Maybe with suitable deprecation step it'd be OK, but not
sure how to make it work for CI constants.
--
Stas Malyshev
smalyshev@gmail.com
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
Usually constant identifiers are treated case-sensitive in PHP. This is
always the case for constants defined via aconstdeclaration.
However,define()allows to passTRUEas 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_DEPRECATEDwhenever the third
argument todefine()isTRUEin 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