That’s not what strict types is about. What you’re pointing our there is not necessarily a failure. Without strict types you can pass a string where an int is expected and PHP will silently cast it for you. This is not a failure. This is perfectly fine behaviour given a loose type system.
So for code that was written with a loose type system in mind, enabling strict types will actually break the code in horrible ways.
That is not to say you shouldn’t use strict types; when given the choice you certainly should IMO. But retrofitting it to existing code may not be the smartest thing to do.
I believe that PHP 7.0 is leading away from being a loose type system and towards a compiled language. Similar to C or Golang where strict typing is essential.
My suggestion was in answer to the following post about upgrading t PHP 7.2:
The example shown does demonstrate the effect of using conflicting function variable type parameters. I would be grateful for a more intuitive example.
I would like to see that happen along with the complete removal of MySQLI.
This is what struck me, that it was about “How to find errors”. I may be mistaken, but it read to me that you were saying (in other posts as well), that enabling strict types was a debugging technique which of course is not what it is for.
Fatal error : Uncaught TypeError: ini_set() expects parameter 2 to be string, integer given in /var/www/test-001.php:5
Stack trace: #0 /var/www/test-001.php(5): ini_set(‘display_errors’, 1) #1 {main} thrown in /var/www/test-001.php on line 5
Edit:
I prefer to throw errors at every opportunity rather than code and trust to Wiki: Type Juggling
Hi John,
I am not sure what the point is your trying to make here.
In your second example you used ini_set twice which means the first one is being overwritten by the second one. Aside from that, the first example uses ‘true’ without strict types which would just as well work WITH strict_types so again, I don’t know what your trying to show.
What “trust”?, What errors? It all works exactly as expected EVERY TIME. What is there to “trust” and what errors are you talking about. I will say it again, strict_types has nothing to do with showing errors or debugging. Feel free to try and show me different.
The strict_types declaration is basically a switch that toggles type juggling (automatic type conversion ). Without it, type juggling is enabled. With it, type juggling is disabled, which means the type already needs to explicitly be exactly what the function expects it to be.
Setting the first ini_set(‘display_errors’, ‘1’); was necessary to ensure errors would be rendered. If the PHP.ini file setting was display_errors = 0 then a blank screen would have rendered.
Seems like you do not want to change to using strict_types and will not be convinced. Have you tried declaring strict_types in some of your old PHP scripts?
May I ask why do you think PHP 7.0 introduced function type parameters?
I believe:
using strict_type option cunningly only applies to the current file and all included files. This was necessary in order to be able to include legacy libraries which could fail and require rewriting.
also that applying the strict option adds an additional level of error reporting
I am also convinced that eliminating type juggling reduces the amount of script which should improve performance, if not today then most likely in future versions. Why not start using the feature now?
Compiled languages usually do not compile if there is a mismatch of variable types. After eliminating conflicts compiled languages usually have better performance.
using strict_types does ensure variables are the correct type
Au contraire! I think strict types are awesome! The point @benanamen and I are trying to make is that it is not a “debugging tool” or causes your code to “fail early”. It might seem that way on new code, but on existing code bases it may break that entire code base because it wasn’t written for strict types.
Example
function sum(int $a, int $b): int
{
return $a + $b;
}
When using strict types, doing sum($_POST['a'], $_POST['b']) will break because everything in POST is strings.
Assuming loose types however, there was nothing wrong with doing that. So suggesting enabling strict types for debugging in that case doesn’t help, it just breaks stuff.
It has nothing to do with wanting to use strict. I actually do use it. All you have to do is look at my code posts and they generally have strict enabled. Convinced of what? That it is for debugging and error trapping? Then no, I wont be convinced. It is plainly clear what strict typing is and what it is for and it has absolutely nothing to do with debugging and catching errors.
You believe? You don’t know?
This is just not correct and has NOTHING to do with legacy libraries.
Strict typing applies to function calls made from within the file with strict typing enabled, not to the functions declared within that file. If a file without strict typing enabled makes a call to a function that was defined in a file with strict typing, the caller’s preference (weak typing) will be respected, and the value will be coerced.
also that applying the strict option adds an additional level of error reporting
NO, NO, AND NO! There is NOTHING whatsoever to do with error reporting. Nothing, nada, zilch.
am also convinced that eliminating type juggling reduces the amount of script which should improve performance,
Again, NO, NO, AND NO!
#4 has nothing whatsoever to do with this.
using strict_types does ensure variables are the correct type
This sentence is very incomplete. It ONLY applies to scalar type declarations (type hints), i.e function parameters and ONLY under certain conditions as plainly explained in the manual. (Ok, a couple more places for completeness: a function’s return type, built-in PHP functions, and functions from loaded extensions.)
John, here is the manual page for strict_types. There is nothing anywhere whatsoever that supports anything you are saying and more importantly, code does not support it.
If you coerce an int to a string, PHP doesn’t flag an error. Not a warning, not anything. If you have strict types enforced and try to coerce an int to a string, it throws an error. So yes, John’s correct that it has something to do with error reporting, namely adding more errors to be reported. Whether its valuable or not to you is an opinion.
They’re still errors, but they’re self-corrected errors by the engine. You’ve still told it to put a square peg in the round hole, but on the way to the hole it smashes the square into a circle mold.
Simple; It’s a logical error, rather than a programmatic one. You told it to use a square peg in a round hole. It corrected your logic to make it work, but you’ve still made the logical error.
Your completely missing the point which I have very clearly made. I said strict types is not for debugging or finding errors. You will not find any valid reference that says it is. I did not say errors would not be generated if you try to use the wrong type with strict enabled. Letting PHP automatically do (type juggling) what it has already done is not an error.