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.

Reply via email to