Hi PHPers,
As I have been following the discussion about the need for a "true" type to allow documenting that a function should only be able to return true vs. bool which would allow false, and in the past the same argument for false vs. true, it occurs to me that there is another approach to address this rather than add values to be types which AFAIK has not been mentioned on the list before.
An alternate solution to possibly consider might be to add the concept of "constraints" to PHP that could work alongside types. This occured to me because I am mostly doing Go programming now and constraints is effectively how Go handled an equivalent conundrum for the Generics they just added.
Consider if PHP allowed the following and if PHP would allow type hints to use either a type or a constraint where the values on the right hand side are expressions (I was just spitballing the syntax; other syntaxes or even concept names might represent this concept better):
constraint true: true
constraint false: false
If we had constraints in PHP we could also have things like this:
constraint Truthy: !empty($this)
constraint Falsey: empty($this)
constraint Percent: is_numeric($this) && 0 <= $this && $this <=100
constraint DateTimeable: is_object($this)
&& (get_class=($this) == DateTime::class || get_class=($this) == DateTimeImmutable::class)
constraint ProductID: is_string($this) && strlen($this)==10
&& preg_match("#[A-Z]{2}[0-9]{8}#",$this)
With the above, we could write functions like this and know they are more "type safe" than otherwise:
function product_exists(ProductID $product_id):bool {...}
Constraints could also be limited to using only standard library functions so that it would be possible to do static analysis on a constraint. Clearly a static analyzer could evaluate the constraints I represented above. And I think this could be backward compatible with false as a type, and even true with a type.
FWIW I am just offering up an approach that seems to have worked well in Go for consideration. If you like it, please discuss it. If not, it was worth a try.
-Mike
P.S. I am sure there are many ways to improve what I proposed. Note this is just a straw man proposal; please offer suggestions for improvement.
Hi PHPers,
As I have been following the discussion about the need for a "true" type to allow documenting that a function should only be able to return true vs. bool which would allow false, and in the past the same argument for false vs. true, it occurs to me that there is another approach to address this rather than add values to be types which AFAIK has not been mentioned on the list before.
An alternate solution to possibly consider might be to add the concept of "constraints" to PHP that could work alongside types. This occured to me because I am mostly doing Go programming now and constraints is effectively how Go handled an equivalent conundrum for the Generics they just added.
Consider if PHP allowed the following and if PHP would allow type hints to use either a type or a constraint where the values on the right hand side are expressions (I was just spitballing the syntax; other syntaxes or even concept names might represent this concept better):
constraint true: true
constraint false: false
If we had constraints in PHP we could also have things like this:
constraint Truthy: !empty($this)
constraint Falsey: empty($this)
constraint Percent: is_numeric($this) && 0 <= $this && $this <=100
constraint DateTimeable: is_object($this)
&& (get_class=($this) == DateTime::class || get_class=($this) == DateTimeImmutable::class)constraint ProductID: is_string($this) && strlen($this)==10
&& preg_match("#[A-Z]{2}[0-9]{8}#",$this)With the above, we could write functions like this and know they are more "type safe" than otherwise:
function product_exists(ProductID $product_id):bool {...}
Constraints could also be limited to using only standard library functions so that it would be possible to do static analysis on a constraint. Clearly a static analyzer could evaluate the constraints I represented above. And I think this could be backward compatible with false as a type, and even true with a type.
FWIW I am just offering up an approach that seems to have worked well in Go for consideration. If you like it, please discuss it. If not, it was worth a try.
-Mike
P.S. I am sure there are many ways to improve what I proposed. Note this is just a straw man proposal; please offer suggestions for improvement.
This reminds me of some of the discussion we’ve had on list of type aliasing.^1
I really like this idea and think it could be combined with type aliasing to create powerful userland-defined types.
While you mention restricting to standard-library functions for easier type-safety, I’m not sure it has to have that limitation. What we’re effectively defining here is a kind of short-hand Closure that is then called with the passed value at runtime to validate the type. A type alias could work similarly, perhaps even with the same syntax.
Cheers,
Ben