| Re: switch with case 0 [message #182621 is a reply to message #182619] |
Sun, 18 August 2013 13:22   |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma:
|
Senior Member |
|
|
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
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.
> 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. 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
from string to number should never happen implicitly -- only explicitly.
> 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`
(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
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]