| Re: switch with case 0 [message #182622 is a reply to message #182621] |
Sun, 18 August 2013 15:20   |
Norman Peelman
Messages: 126
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 08/18/2013 09:22 AM, Thomas Mlynarczyk wrote:
> Norman Peelman schrieb:
>
>> Why is it unreasonable? After all, FORM data is all strings to begin
>> with. PHP will type juggle "12345" to 12345 just fine. The whole idea
>> behind this after all is not about having strings like "2foo".
>
> GET/POST data arrive as strings, yes. So the first thing one does in a
> PHP script is to validate that data and convert it *explicitly* to the
PHP started *before* the big validation era...
> correct type. One does not "leave" it as string and expect PHP to
> convert it *implicitly* later on, because one may well have cases where
> there is a string like "42" or "2foo" which is supposed to remain a
> string and be treated as a string and not as a number.
>
PHP doesn't just randomly decide to type juggle, it does so in
context. If you want a string "42", you have it. PHP won't do anything
to it until you try to do some math with it (or explicitly ask it to do so.)
>> FORM data, GET/POST data, all strings...
>
> I heard you the first time.
>
>>>> >>> switch ($mode) {
>>>> >>> case SORT_ASC:
>>>> >>> case SORT_DESC:
>>>> >>> case SORT_REGULAR:
>>>> >>> case SORT_NUMERIC:
>>>> >>> case SORT_STRING:
>>>> >>> case SORT_LOCALE_STRING:
>>>> >>> case SORT_NATURAL:
>>>> >>> case SORT_FLAG_CASE:
>>>> >>> break;
>>>> >>> default:
>>>> >>> throw new \InvalidArgumentException("invalid sort mode:
>>>> >>> $mode");
>>>> >>> }
>>>> >
>
>>> No I'm not assuming that. If all the SORT_* constants are integers, then
>>> only the default branch should match in that case. It doesn't in PHP,
>>> because PHP is made to implicitly convert strings to integers.
>>
>> No, the only time the default is reached is when $mode is outside 0-7
>
> I wrote "in that case" referring to $mode = "foo".
>
>> (I say that because i only have 6 of the 8, I haven't updated yet.) If
>> $mode = E_ERROR it still validates. This code does nothing to ensure
>> $mode is what it is supposed to be.
>
> Yes, different constants could have the same value and there is no way
> for PHP to tell which one was "used" to pass the value. So you could
> pass E_ERROR instead of SORT_FOO if both happen to have the same value.
> It would be nice, though, to be able to detect that.
>
>>
>> What about:
>> -- code --
>> $mode = setSortMode("SORT_NUMERIC");
>> echo $mode."\n";
>
> That would be a workaround to achieve the above. But I find it not very
> elegant to use a string in this case.
>
>> Technically speaking, the user should not be able to *choose* an
>> invalid mode but if they somehow did, I believe it should default to
>> some normal behavior (even if the result isn't what they wanted.) In
>> other words, default to SORT_REGULAR (pick your poison) until another
>> *valid* option is chosen.
>
> Or the code should throw an exception if an invalid argument is passed.
> (After all, it's the programmer's job to ensure no invalid arguments are
> passed to any function, so if it happens, it's the programmer's fault
> and must be fixed.)
>
>>> I am aware of the fact that PHP will try to convert the string into a
>>> number (even when this would not possibly make any sense).
>>
>> How do you know when it wouldn't make sense?
>
> Trying to convert "foo" to a number doesn't make sense. It only makes
> sense when the string contains the representation of a number.
Thomas, methinks you've decided to be dense... PHP has to *look* at
the string to determine that.
> That said, if there happened to be a defined constant foo = 42, then (int)
> "foo" could reasonably result in int(42). But in any case, a conversion
There is no constant "foo". If created, it would be foo. So, no
(int)"foo" should not result in a constant foo value. constant("foo")
does that just fine.
> from string to number should never happen implicitly -- only explicitly.
>
PHP type juggles when you ask it to do so (right/wrong/mistake). If
it did it implicitly then it would happen before you ever got to the data.
>> FORMS, GET/POST data = strings...
>
> I heard you the first time.
>
> But just to be clear, let me repeat myself once more: *explicit*
> conversion from string to number is okay as long as it returns `null`
"foo" + 2 = 2
NULL + 2 = 2
> (or some other appropriate indication) in case of the string not
> representing a valid number. *Implicit* conversion from string to number
> is bad. Whenever there's a string and a number and PHP is supposed to do
> something with them (like comparing via `<=`), it should convert the
> number to a string and not the other way round.
>
> Greetings,
> Thomas
>
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]