Strict types make it easier to reason about code, that the tl;dr version.
> To me it seems that Ze'ev's proposal would be even better for you -
> it does the equivalent of the validation and conversion automatically
> including with an error if it doesn't validate.
Rather than having int 'types' which we can reason about, it has int 'values' which are harder to reason about. Types can be reasoned about just by looking at the code. Values can only be reasoned about when running code. A contrived example:
function foo(int $bar){...}
foo(36/$value);
In strict mode, this would be reported as an error by code analysis.
For the coercive scalar type proposal, this code works - except when it doesn't. This code works when $value = 1, 2, 3, 4 and breaks when $value = 5.
This is the fundamental difference; whether conversions between types have to be explicitly done by code, and so any implicit or incorrect conversion can be detected by static code analysis tools, or whether the conversions are done at run time, and so cannot be analyzed fully.
This means most of these errors will be discovered by users on the production servers. Strict mode allows you to eliminate these types of errors.
Yes, this means I need to add a bit of code to do the explicit conversion, but I just don't convert between values that much. Once a value is loaded from a users request, config file or wherever, it is converted once into the type it needs to be. After that, any further change in type is far more likely to be me making a mistake, rather than an actual need to change the type.
> Any idea why it was rejected so badly? Is it because the coercion rules are different from the rest of PHP?
At least in part it was because the RFC was seen as a way to block strict types; about half of the RFC text is shitting on people desires for strict types, which did not make people who want strict types be very receptive. If it had been brought up 6 months ago, there is a good chance it would have passed, or at least would have been closer.
Some parts of the proposal were good - other parts were nuts that were pretty obvious the result of the RFC only being created once the dual mode RFC was announced and about to be put to the vote, with a very high chance of passing.
* Good - "7 dogs" not longer being converted to "7" if someone tries to use it as an int.
* Bad - Different mode for internal function vs userland functions e.g. "Unlike user-land scalar type hints, internal functions will accept nulls as valid scalars." and other small differences. This is even more nuts than you might realise as it means if you extend an internal class, and overload some of the methods on the class, those methods will behave differently to the non-overloaded methods.
* Bad - Subtle and hard to fix BC breaks in conversion which are probably not right anyway. e.g.
false -> int # No more conversion from bool
true -> string # No more conversion from bool
It is a shame that the discussion became so contentious. It would have been good if the conversion rules could have been tidied up, but all the time and energy had been used up the not particularly productive discussion.
Strict types make it easier to reason about code, that the tl;dr version.
> To me it seems that Ze'ev's proposal would be even better for you - > it does the equivalent of the validation and conversion automatically > including with an error if it doesn't validate.
Rather than having int 'types' which we can reason about, it has int 'values' which are harder to reason about. Types can be reasoned about just by looking at the code. Values can only be reasoned about when running code. A contrived example:
In strict mode, this would be reported as an error by code analysis.For the coercive scalar type proposal, this code works - except when it doesn't. This code works when $value = 1, 2, 3, 4 and breaks when $value = 5.
This is the fundamental difference; whether conversions between types have to be explicitly done by code, and so any implicit or incorrect conversion can be detected by static code analysis tools, or whether the conversions are done at run time, and so cannot be analyzed fully.
This means most of these errors will be discovered by users on the production servers. Strict mode allows you to eliminate these types of errors.
Yes, this means I need to add a bit of code to do the explicit conversion, but I just don't convert between values that much. Once a value is loaded from a users request, config file or wherever, it is converted once into the type it needs to be. After that, any further change in type is far more likely to be me making a mistake, rather than an actual need to change the type.
> Any idea why it was rejected so badly? Is it because the coercion rules are different from the rest of PHP?
At least in part it was because the RFC was seen as a way to block strict types; about half of the RFC text is shitting on people desires for strict types, which did not make people who want strict types be very receptive. If it had been brought up 6 months ago, there is a good chance it would have passed, or at least would have been closer.
Some parts of the proposal were good - other parts were nuts that were pretty obvious the result of the RFC only being created once the dual mode RFC was announced and about to be put to the vote, with a very high chance of passing.
* Good - "7 dogs" not longer being converted to "7" if someone tries to use it as an int.
* Bad - Different mode for internal function vs userland functions e.g. "Unlike user-land scalar type hints, internal functions will accept nulls as valid scalars." and other small differences. This is even more nuts than you might realise as it means if you extend an internal class, and overload some of the methods on the class, those methods will behave differently to the non-overloaded methods.
* Bad - Subtle and hard to fix BC breaks in conversion which are probably not right anyway. e.g. false -> int # No more conversion from bool true -> string # No more conversion from bool
It is a shame that the discussion became so contentious. It would have been good if the conversion rules could have been tidied up, but all the time and energy had been used up the not particularly productive discussion.