Hacker News Reader

Comment by shubhamjain | Hacker News Reader

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...

View on HN

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).

> 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.

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.

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.)

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.

Yes. To be strictly fair, both JS and PHP have legitimate excuses; JS because it was done in an insanely short timescale, PHP because it was (initially at least) cobbled together by an amateur for his own purposes. I doubt anyone could have predicted that both languages between them would basically be running the planet by 2015 :)

They're sorry you're such a terrible coder, worse than Rasmus Lerdorf himself:

"For all the folks getting excited about my quotes. Here is another - Yes, I am a terrible coder, but I am probably still better than you :)" - http://en.wikiquote.org/wiki/Rasmus_Lerdorf

> 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.

Spoiling a good rant with facts.

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.

But beware, with strict comparison: 1 ≠ 1.0 (because int ≠ float).

But... wouldn't you expect that?

I mean, they AREN'T the same value really.

Agree, they aren't the same type to begin with.

    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?

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.

While it is obvious that PHP's == operator is horrible, JavaScript has its share of pretty bad issues, like "x" - 1 giving NaN.

What I don't understand is why some people agree that PHP is a horrible language, while at the same time praising JavaScript as messiah of scripting. These two languages don't just have problems, they have very similar problems. Moreover, they gained popularity for very similar reasons (lack of choice).

Seriously, if you posted something similar to OP about JavaScript the first thing people would tell you is "What, you're still not using ===?!"

PHP: var_export(0 == "hello"); // true

JavaScript: console.log(0 == "hello"); // false

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?

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.

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.

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 :).

Reply on news.ycombinator.com