"Alain Williams" wrote in message
news:20170924120754.ga4...@phcomp.co.uk...
On Sun, Sep 24, 2017 at 11:52:49AM +0100, Lester Caine wrote:
That sums it up nicely Alain ...
Now the question is actually ... do we stay in the dark ages of single
byte character sets or do we move to fully embrace a current well
established and extensively used standard. Unicode has perhaps shirked
on the matter of 'case-insensitive' so there is no clean solution to
that today. That should not prevent the switch to unicode and other
threads such as the csv routines are now highlighting additional 'edge
cases' where unicode needs addressing, or kicking into the long grass of
extensions of mbstring? Maintaining 'case-insensitive' for single byte
character sets is an option, but then one needs to stay with that for
the whole code functionality? Allowing multibyte constant names with the
current limited sub-set of case conversion is just not sensible, but in
the absence of a clean unicode case folding/conversion which is the
sensible next step?
We also need to think about how our decisions here affect how PHP is used;
in
particular robustness, correctness, ... of code that people write. I
believe
that one attribute of the mind of a good programmer is
precision/exactness -
eschewing sloppyness. Thus if a function is written DoSomething() then it
should
be spelled that way, not doSomething(), etc.
It does absolutely no harm i different case is used. I agree that it is
wrong from a "purity" point of view, but it does NOT cause a genuine problem
(except in the minds of a few nit pickers). However, the solution that you
appear to support would definitely cause problems as we humans are used to
living in a case insensitive world:
- when we search for a word in a dictionary we do not have to specify the
exact case to get an exact match.
- when we search for a file on a user-friendly file system we do not have to
specify the exact case to find a match.
- when we search for a word inside a file we do not have to specify the
exact case to find a match. Some editors provide an option for a case
sensitive search, but the default is case INsensitive.
What do you think is going to happen when keyboard input is replaced by
voice input? Will we be able to just say a word, or will we have to spell it
out character by character in order to specify the case of each? Try selling
THAT idea and seehow far you get.
Also PHP programmers are likely to write Javascript - which is case
sensitive.
The fact that some languages are case sensitive is not a valid argument for
making all languages case sensitive. Most languages which came before
javascript were case insensitive, so perhaps it's time for javascript to
make itself consistent with those languages.
I have also seen problems where someone has developed code using Microsoft
SQL,
they are then asked to port it to a case sensitive database, eg MySQL**.
MySQL is NOT case sensitive. I have been using it for nearly two decades,
and when I construct an SQL I can use either upper or lower case without any
problems.
Or an application written on a case insensitive file system (Eg MS Windows)
and
then try to deploy it on Linux: only to have includes & fopens fail because
they
have been inconsistent in how they wrote file names. [[ I do not want to
get
into a discussion about the rights/wrongs of case (in)sensitive file
names - we
must just accept that as part of the world that we live in. ]]
So encouraging the ''names are case sensitive'' meme is, IMHO, good.
Then look at the internals of the PHP engine. Case insensitively adds
complexity (== places for bugs to lurk) and makes it slower - name lookup
happens a lot, it is not just a once off (& off line) compilation process.
Just because you cannot fix a feature which only causes a problem in a few
cases is no excuse to remove that feature completely.
Some
of us work hard to make the PHP engine 0.5% faster - so why make it slower
with
something that we can easily avoid ?
If keeping the language simple and fast is the objective, then why do I keep
seeing RFCs which propose ways of combining several simple functions into a
complex one just because the author wants to achieve something with fewer
keystrokes? Making the language more complicated for the benefit of a
minority, as well as creating code which is less readable, should be
something that is avoided, not promoted.
Yes: case insensitivity is nice, I have that option set in my program
editor
search; but I am a programmer; to use PHP I have to put in a lot of effort
to
learn how to do things -- the same is true for any programming language. We
are
not talking about real end users such as my mother $$ - people who we try
to
make our systems usable for without having to train them.
You ask what to do ?
I suggest that case insensitiveness in single byte character sets (constant
&
function names) should be depricated, but enabled for one major release
with an
init flag -- just as was done for register_globals. That would give
everyone a
couple of years to tidy their code up.
Do you realise how much of a BC break this would be? For what benefit? Just
to satisfy your idea of "purity"?
Then kill case insensitve anything in PHP [[ other than the likes of
strcasecmp() ]].
**OK: MySQL has a switch to make table names, etc, case insensitive - but
enabling that means a lot of testing to ensure that nothing else breaks.
$$ I don't want to be rude about her, so maybe I ought to use a different
group
of clueless people, politicians perhaps ? :-)
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
