Hooray! \o/
I haven't had a use for this yet, but I'm always amazed by how PHP manages to move forward without breaking BC.
I haven't had a use for this yet, but I'm always amazed by how PHP manages to move forward without breaking BC.
I've had cases where I want to only allow certain values (most often int) into certain functions (usually __construct, when looking at a primary key in a database), but in these cases I prefer to cast values. (int)$foo hasn't failed me yet, and I've internalized it as much as I've internalized running application output through htmlentities.
I can see this being extremely useful if you plan on using PHP as a general purpose language, but I never have. I'd rather jump to Java/C++/Rust if I had to do numeric calculations (things like images, real time calculations, etc.)
You pull out a particular row from this library/extension, and it contains an empty string (or even null) as the value for the primary key field.
Using typecasting, you'd get a value of 0, which is wrong. It would fail silently, and you'd only discover the error when you realize you're working on a row with no data. You'd even be able to update the row silently, because "UPDATE whatever SET x = y WHERE id = 0" is valid SQL!
With primitive type hints, you'd know immediately that you're getting an empty value from your DB, and you could go straight to fixing that instead.
In the past, people have had to write a bunch of unit tests to avoid all these issues. With primitive type hints, you could just type the word "int" and be done with it.
All that said, I still say all the people that are excited about this are much better off switching to a strictly-typed language, because my example above is just the tip of the iceberg when it comes to juggling types.
Off the top of my head, here's a case where they changed the output of a hash function between 5.3 and 5.4, breaking it for all previous users. https://bugs.php.net/bug.php?id=60221
Well, at least you know what you're getting into. It's not like they promise otherwise anywhere.
This. If I were a Python developer (of the language itself), I would be paying very close attention to how PHP has handled deprecation and breaking changes.
And also the jump from 5.4+ to 7 is probably smaller than the jump from 5.2 to 5.3.
Although I think the PHP project does need to support versions for longer, the adoption rate of 7 is going to be quite rapid due to the low barrier of doing it, and the massive performance and language gains.
I understand why some people prefer that, and why it's the way most languages go (Java does the same thing, just with way less movement in general compared to PHP), but it means that the language gets worse over time. Eventually, if you don't do that breaking change, the language will get replaced by something that doesn't need all the cludge.
Bad analogy, but the point is that Python still worked for most people so the upgrade process was slow.
I think Go is going to have issues similar to Python when they make the jump to 2.0. The devs are already on record saying that BC will break.