| Re: switch with case 0 [message #182623 is a reply to message #182622] |
Sun, 18 August 2013 16:28   |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma:
|
Senior Member |
|
|
Norman Peelman schrieb:
> PHP started *before* the big validation era...
This may be true, but does that mean we should not validate in PHP? ;-)
> 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.)
Well, unfortunately, <, <=, >, >= and switch give you no possibility to
prevent unwanted string->int casts. For equality checks, you can use ===
and !==, but there are no corresponding operators for <, > etc. And
that's the problem.
>> 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.
Methinks differently, but... Of course, PHP has to look. Just looking is
okay. Messing up is not. But if PHP never tried to look at the string by
itself -- only when being told to -- things would be much better.
>> 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.
Oh come on, my English is certainly not perfect, but please -- just a
little effort trying to understand what I say...? Again:
Suppose you have a string "foo" and your task is to convert it to an
integer. Normally, you'd think there's no reasonable way to do that. But
if there happened to be a constant foo = 42 defined, it would seem
reasonable to assume that the string "foo" might refer to that constant
and therefore convert "foo" to 42. No, I'm not talking about what PHP
*is* currently doing in such a situation, I'm talking about how a
computer language should be designed to behave in such a situation.
> 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.
With "foo" < 42, PHP will convert "foo" to 0 and then "do" 0 < 42.
That's what I call implicit conversion and please correct me if my usage
of that word happens to be wrong. Explicit would be (int) "foo" < 42.
> "foo" + 2 = 2
> NULL + 2 = 2
It boils down to this: "foo" + 2 doesn't mean anything. In order to mean
something, both operands must be of the same type. So, either
"foo" + (string) 2 = "foo" + "2" = "foo2"
as other languages would handle this, or
(int) "foo" + 2 = ??? + 2 = ???
or throw an exception to complain about incompatible operands.
If (int) $somevar yields 0 with $somevar = "foo", then I have no way of
knowing whether the 0 is the "legitimate" result of the cast or whether
it just means "couldn't cast that to a number, giving you back 0
instead". But if in case of failure `null` is returned, I can look at
the result of (int) $somevar and if it's `null` (and not an integer) I
know the cast failed and I can react accordingly.
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
]