Any programmer in almost any language who mixes types like that without understanding the implicit type conversion semantics is asking for trouble.

Implicit type conversion is evil, and I don't see how PHP's sin of favouring string -> number over number -> string is any worse than, say:

    // Javascript
    console.log(+(+!![]+(+[]+[]))); // outputs the number 10

Or:

    // C, Java

    float celsius, fahrenheit1, fahrenheit2;
    celsius = 100;

    fahrenheit1 = celsius * 9 / 5 + 32;
    fahrenheit2 = 9 / 5 * celsius + 32;

    assert(fahrenheit1 == 212); // OK
    assert(fahrenheit2 == 212); // Oops!  It's 132.  What happened?

Javascript, C and Java suck, yes. Show me something as bad as the OP in python3 and then maybe you'll have a point.

Even if Python 3's type conversion semantics has no dark corners, I still have a point.

harshreality argued that, because PHP's implicit type conversion leads to weird behaviour, "PHP doesn't work. End of story."

In that case, nearly every widely used language (with the possible exception of Python 3) "doesn't work. End of story." That's not a very interesting or useful story to tell.

Javascript, C and Java all "don't work", at least to the extent that I would never take a job writing them.

Well, you're consistent.

As I said earlier, I agree that implicit type-conversion is evil. But if I refused to use flawed tools...

I've been coding PHP for almost 8 years now. The number of times that I have come across anything even close to that example is precisely zero.

8 is sane here. The + operator adds numbers. It converts the string to a number implicitly in the process. it takes "0x4zz5" and tries to parse as much as possible. Since "z" is not a valid hexadecimal digit, it stops at z, and reads it as 0x4.

Of course, it is better to manually convert.

Well, I'd say it's never better to "try to parse as much as you can" and when encountering such an error simply silently give out a nonsense answer.

It's the computer equivalent of a bozo worker who does something random everytime they don't know how to do their job, and then tries to hide any consequences while whistling innocently.

It's not equivalent at all. It is an expected, clearly-defined behaviour - automatic, silent type conversion, with clear rules on how that type conversion works.

I'd bet 1-to-10 that if someone uses '+' operator then that line of code is never expected to encounter "0x4zz5" there. And I'm pretty sure that this addition is not meant to return a number exactly 4 less if it encounters "0z4zz5" instead of "0x4zz5". There is some theoretical chance that it does, but really, it's a lottery-type chance.

The whole total function has something that it's expected to do, some value that it returns in the end - and if it can't do that then any returned value is useless and wrong anyway; and automatic, silent type conversion is the worst possible choice of action, since it not only doesn't work, returning a value that you didn't intend (as other options); but in addition makes the actual bug hard to find and potentially corrupts a lot of stored data before you find the bug.

Things like this and some interesting developments from Facebook concerning them are mentioned in the presentation, so it would be nice if people would actually discuss that. Just a suggestion.

It's PHP. Unfortunately, enough developer got bit by the fact that PHP doesn't prevent you from shooting yourself in the foot, and shot themselves in the foot.

So, you'd probably be pretty ornery too when other people had more discipline to use the language without shooting their foot and were also employing it successfully. You'd probably want to make assumptions, and word hard to belittle them. Insult them.

And they'll talk about beauty. And zen. And wonder, and joy in a language. And they'll gloss over the major problems that it suffers from. They'll imagine all is well. And they'll try and tell you that nothing good can come from the tool they once used to shoot themselves in the foot.

Just walk away. Because you still have two feet.

PHP may have a bunch of ways to shoot yourself in the foot, but you get a new foot back right away. IMHO the oddities in PHP rarely hit you, and when they do you'll pick it up right away in PHPUnit, fix it, and walk away.

Sorry, maybe it wasn't clear, but the professional using PHP was the one walking away. =)

Yes I think I misunderstood, thanks for correcting.

Second this -- it's not only mentioned, they talk about a path to addressing this and other problems.

As a PHP developer I entirely assume that is going to print 8. I'm sure every PHP developer has had it happen or ran across it in the manual: when strings are forced into int positions PHP uses the numbers from the front of the string. Its unexpected, but consistent.

Keying it to an int via the tip of the string? Let's call it iceberg-typing.

It's PHP concatenation operator is ".".

  print $productid . 4;

You missed the point, and the problem. PHP tries way too hard to try to mangle input to kinda sorta work with the operators at hand. Were it a reasonable language, it would throw out a warning, or better yet, an error, to handle a fairly broken situation like this, rather than try to pick and choose the parts of the string it thinks is appropriate.

> a fairly broken situation

You missed the problem as well. Don't ask for trouble by creating broken situations.

Who the hell tries adding 4 to a product identifier?

I wish I could use static typing too, but when I can't I use vars that are somewhat intuitive.

How is that relevant to anything? What kind of projects do you work on where this is a problem?

Why does productid have weird number like that? Normal PI0x4zz5 instead of 0x4zz5 or just numeric figure