5 ms·

PHP's type coercion is nothing like I have every seen in any other language. Its horrendously messy, ugly and completely inexcusable. Strings type-casted to int

PHP's type coercion is nothing like I have every seen in any other language. Its horrendously messy, ugly and completely inexcusable. Strings type-casted to integers are 0. Seriously? Take a look at this, > $arr = array(0, "was", "invented", "in", "india"); > var_dump( in_array("Hello", $arr ) ); and yeah it is TRUE because "Hello" got coerced to 0. I blogged about a major bug, I faced, in PHP, where column name "10th_grade" was being type-casted to "10" failing the "bindParam" [1]. Even if they have to continue this "feature" because of backwards compatibility, the least they could have done was NOT to use it in the newer functions but no, even they have this stupid "type juggling". [1]: http://coffeecoder.net/blog/my-perfect-reason-avoid-php-type-juggling/ http://coffeecoder.net/blog/my-perfect-reason-avoid-php-type...

Rygu 12y ago
> in_array(.., .., $strict) I think you're aware of the third parameter but for anyone who reads this post, it disables the type coercion of the in_array call.
- z92 12y ago
  Spoiling a good rant with facts.
  - pdpi 12y ago
    The fact that you need to specify a third, optional parameter to get sane output out of a really basic function is still pretty rant-worthy.
- mrtbld 12y ago
  But beware, with strict comparison: 1 ≠ 1.0 (because int ≠ float).
  - lsaferite 12y ago
    But... wouldn't you expect that? I mean, they AREN'T the same value really.
    - Rygu 12y ago
      Agree, they aren't the same type to begin with.
WalterGR 12y ago
PHP's type coercion is nothing like I have every seen in any other language. Its horrendously messy, ugly and completely inexcusable. Is it objectively worse than type coercion in JavaScript?
- eurleif 12y ago
  PHP: var_export(0 == "hello"); // true JavaScript: console.log(0 == "hello"); // false
  - deleted 12y ago
    [deleted]
  - WalterGR 12y ago
    Actually, I was hoping for something more than a single example. Or, did you mean that PHP and JavaScript were neck-and-neck all the way up to that one example, and ultimately it's the very one that proves PHP's type coercion is worse?
    - eurleif 12y ago
      You're in a thread about how PHP's type coercion can easily cause a serious vulnerability. So, the title of this thread is your second example. If you want a third example, find it yourself.
      - WalterGR 12y ago
        Give me a break. 3 examples isn't enough to answer the question. Your comment history shows you ask questions in lieu of doing your own research. If you don't want to take the time, then move on.
- oisyn 12y ago
  Oh yes. In Javascript, the operands are only coerced if one of the operands is a number. So when comparing two strings (regardless of whether the strings can be interpreted as a number), you always get a regular string compare. "12" == "12.0" -> false, basic string compare Furthermore, if one operand happens to be a number, and the other operand has illegal characters to be interpreted as a number, the two operands aren't equal. 0 == "foo" -> false, "foo" is not a valid number 12 == "12 monkeys" -> false, "12 monkeys" is not a valid number 12 == "12.0" -> true, "12.0" is a valid number, and compares equal to 12. In short, in Javascript the == operator actually makes sense. In PHP, every single one of above examples would evaluate to true.
tragomaskhalos 12y ago
There are a couple of things we have learnt in our collective 50+ years of software engineering: 1. Code is not English: Nice try COBOL, and someone had to try, but a failed experiment. Bizarre holdouts: SQL 2. People are not idiots, and will not collapse into a gibbering heap if their programming language insists that 0 and "0" are different things and must be managed accordingly. Bizarre holdouts: PHP, Javascript. Honourable mention: Excel (no Excel, that is not a f&@cking date, I will tell you if I want a date).
- TeMPOraL 12y ago
  > 2. People are not idiots, and will not collapse into a gibbering heap if their programming language insists that 0 and "0" are different things and must be managed accordingly. This. People are not idiots, they're learning. By making your language assume programmer is an idiot you're making it more difficult for said programmer to form a coherent mental model of what's going on.
- userbinator 12y ago
  Bizarre holdouts: SQL I think SQL is actually one of the better implementations of this idea. It's a bit verbose, but I don't think it's tripped up people in the same way that PHP and JS do.
  - tehwalrus 12y ago
    SQL is great for a very specific job: talking to a database. If you try to do anything else in it, you end up in a horrible mess (e.g. cursors). Luckily, people rarely try to do anything difficult in SQL, because they are using another language and dropping into SQL to talk to their database. This can lead to inefficient code, depending on the API/SQL engine, but it means people end up with sane code (unless their other language is PHP, of course.)
- aikah 12y ago
  Absolutely, to be fair to JS, Eich admitted it was an horrible mistake, and tools like JSlint enforce the use of === . I didn't see any meaculpa from the PHP team yet.Would like to read about it.
daenney 12y ago
Amusingly enough the Puppet current parser does this too because it has some weird form of type juggling. This has been fixed in the future parser, which actually has a type system too :).

Rygu 12y ago

> in_array(.., .., $strict) I think you're aware of the third parameter but for anyone who reads this post, it disables the type coercion of the in_array call.

z92 12y ago
Spoiling a good rant with facts.
- pdpi 12y ago
  The fact that you need to specify a third, optional parameter to get sane output out of a really basic function is still pretty rant-worthy.
mrtbld 12y ago
But beware, with strict comparison: 1 ≠ 1.0 (because int ≠ float).
- lsaferite 12y ago
  But... wouldn't you expect that? I mean, they AREN'T the same value really.
  - Rygu 12y ago
    Agree, they aren't the same type to begin with.

WalterGR 12y ago

PHP's type coercion is nothing like I have every seen in any other language. Its horrendously messy, ugly and completely inexcusable. Is it objectively worse than type coercion in JavaScript?

eurleif 12y ago
PHP: var_export(0 == "hello"); // true JavaScript: console.log(0 == "hello"); // false
- deleted 12y ago
  [deleted]
- WalterGR 12y ago
  Actually, I was hoping for something more than a single example. Or, did you mean that PHP and JavaScript were neck-and-neck all the way up to that one example, and ultimately it's the very one that proves PHP's type coercion is worse?
  - eurleif 12y ago
    You're in a thread about how PHP's type coercion can easily cause a serious vulnerability. So, the title of this thread is your second example. If you want a third example, find it yourself.
    - WalterGR 12y ago
      Give me a break. 3 examples isn't enough to answer the question. Your comment history shows you ask questions in lieu of doing your own research. If you don't want to take the time, then move on.
oisyn 12y ago
Oh yes. In Javascript, the operands are only coerced if one of the operands is a number. So when comparing two strings (regardless of whether the strings can be interpreted as a number), you always get a regular string compare. "12" == "12.0" -> false, basic string compare Furthermore, if one operand happens to be a number, and the other operand has illegal characters to be interpreted as a number, the two operands aren't equal. 0 == "foo" -> false, "foo" is not a valid number 12 == "12 monkeys" -> false, "12 monkeys" is not a valid number 12 == "12.0" -> true, "12.0" is a valid number, and compares equal to 12. In short, in Javascript the == operator actually makes sense. In PHP, every single one of above examples would evaluate to true.

tragomaskhalos 12y ago

There are a couple of things we have learnt in our collective 50+ years of software engineering: 1. Code is not English: Nice try COBOL, and someone had to try, but a failed experiment. Bizarre holdouts: SQL 2. People are not idiots, and will not collapse into a gibbering heap if their programming language insists that 0 and "0" are different things and must be managed accordingly. Bizarre holdouts: PHP, Javascript. Honourable mention: Excel (no Excel, that is not a f&@cking date, I will tell you if I want a date).

TeMPOraL 12y ago
> 2. People are not idiots, and will not collapse into a gibbering heap if their programming language insists that 0 and "0" are different things and must be managed accordingly. This. People are not idiots, they're learning. By making your language assume programmer is an idiot you're making it more difficult for said programmer to form a coherent mental model of what's going on.
userbinator 12y ago
Bizarre holdouts: SQL I think SQL is actually one of the better implementations of this idea. It's a bit verbose, but I don't think it's tripped up people in the same way that PHP and JS do.
- tehwalrus 12y ago
  SQL is great for a very specific job: talking to a database. If you try to do anything else in it, you end up in a horrible mess (e.g. cursors). Luckily, people rarely try to do anything difficult in SQL, because they are using another language and dropping into SQL to talk to their database. This can lead to inefficient code, depending on the API/SQL engine, but it means people end up with sane code (unless their other language is PHP, of course.)
aikah 12y ago
Absolutely, to be fair to JS, Eich admitted it was an horrible mistake, and tools like JSlint enforce the use of === . I didn't see any meaculpa from the PHP team yet.Would like to read about it.

daenney 12y ago

Amusingly enough the Puppet current parser does this too because it has some weird form of type juggling. This has been fixed in the future parser, which actually has a type system too :).