Re: switch with case 0 [message #182629 is a reply to message #182626] |
Mon, 19 August 2013 02:13 |
Norman Peelman
Messages: 126 Registered: September 2010
Karma:
|
Senior Member |
|
|
On 08/18/2013 06:13 PM, Thomas Mlynarczyk wrote:
> Norman Peelman schrieb:
>
>> $mode = "fop";
>> echo (($mode === "$mode") AND ($mode <= "foo")) ? "True\n" : "False\n";
>
> False. And no surprise. This is more fun:
>
> // Transitivity...?
> var_dump( "10" < "foo", "foo" < 2, "10" < 2 );
"10" < "foo" == TRUE - alphabetically numbers are lower than letters.
But "10" is shorter in length than "foo" so it is less than by default.
"foo" < 2 == TRUE - "foo" == 0 (since it isn't greater than 0). "foo" is
cast because of the integer 2.
"10" < 2 == FALSE - cast as above.
>
> // Foo is both greater and smaller than 1?
> var_dump( "1" == 1, "foo" > "1", "foo" < 1 );
"1" == 1 == TRUE - cast as above.
"foo" > "1" == TRUE - both alphabetically and length. no cast.
"foo" < 1 == TRUE - cast as above
>
> // Appending the same character on both sides...
> var_dump( "xe" > "x0", "xe2" > "x02" );
"xe" > "x0" == TRUE - alphabetically, no cast.
"xe2" > "x02" == TRUE - alphabetically, no cast.
> // ... should not change the result
> var_dump( "1e" > "10", "1e2" > "102" );
"1e" > "10" == TRUE - evaluated as strings because "1e" does not cast to
10 ("1e1" does though.)
"1e2" > "102" == FALSE - evaluated as numbers because both strings are
numerical. You have me on this one. I understand casting when at least
one side is INT/etc. but when both are strings they should be evaluated
as strings. That is implicit casting. And there is no reason for it. :)
>
> Yes there are rules that PHP follows to create all this madness and it's
> all documented. But why wasn't it made as simple and intuitive as in
> other languages?
>
>> When you are comparing things, you are asking PHP to look at them...
>
> Yes. But PHP should not turn strings into numbers before doing the
> comparison. It should rather turn numbers into strings, if necessary.
>
>> To me that's the same problem in reverse. + is math, . is
>> concatination. + needs/wants numbers, . needs/wants strings. You don't
>> ADD strings, you JOIN/CONCATINATE them.
>
> Okay, + wants numbers. So "foo" + 2 is an error. Silently turning "foo"
> into 0 hides this error instead of slapping it into the programmer's face.
We are going in circles at this point... PHP just isn't made that way
so I can't keep arguing about it. Again, I get the basic casting method
up but not including casting two strings to compare them as numbers. If
it's because functions like *strcmp()* are for strings then maybe *that*
should be handled silently:
"1e2" < "102" == strcmp("1e2","102") // dunno about that - seems clumsy
Technically speaking, there are only two STRING operators listed:
.. concatenation
..= append
....everything else is function based for strings. You've partially
changed my mind Thomas. That you have.
>
>> Ok Thomas, lets think this through. If a string $somevar contains a
>> number, you get cast that number. If the cast results in 0 because
>> $somevar either does not contain a number or contains "0", does it
>> matter?
>
> Yes, I think it does matter. When I'm expecting something that resembles
> a number and I get something that does not resemble a number, then
> clearly there's something wrong and the situation should be handled in a
> special way. There may be cases, where the silent conversion to 0 is
> desirable, but the default behaviour should be an error.
>
>> If 0 is not an acceptable result, you the programmer should more than
>> likely be coding for that anyway.
>
> Yes, I (as the programmer) should make sure not to try adding "foo" + 2.
> But what about my var_dump() examples above? What if I want to compare
> "1e2" > "102" as strings and not as numbers (100 > 102)? I'd have to
> resort to substr_compare() to achieve that. With PHP, there's usually a
> way to get what you want, but it's not always the simplest and most
> obvious way. And thus one must be careful with this language to avoid
> all the pitfalls. Once I wrote by mistake
>
> if ( strlen( $string <= 64 ) ) // note the misplaced `)`
>
> and it worked like a charm -- for months. Until a had $string values
> starting with numbers... Did PHP complain? No. First it did its weird
> comparison and then it passed the resulting boolean to strlen() and
> strlen() didn't complain, converted the boolean to string, did its
> stuff, returned an integer which got converted to a boolean to evaluate
> the if condition. If you ever make a mistake and want to hide it -- put
> it in a PHP script, it'll be safe there ;-)
>
> Greetings,
> Thomas
>
>
I still think most of it when used properly can aid a programmer. A
big part of our discussion is actually two different things. You want
PHP to let you know up front like a compiler would. And i'm thinking
about how to use casting to my advantage. Might start a new topic about
that...
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|