Re: [RFC] Interval Comparison

From: Date: Sun, 06 Nov 2016 21:43:55 +0000
Subject: Re: [RFC] Interval Comparison
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-96748@lists.php.net to get a copy of this message
On Sun, Nov 6, 2016 at 1:59 PM David Rodrigues <david.proweb@gmail.com> wrote: > I guess that the biggest problem is about the code parsing. Currently PHP > should supports what you wrote, but with another meaning. And personally I > think that this feature is not too common on programming language in > general, once that it is possible from first format (maybe more clear too). > > Em 6 de nov de 2016 6:30 PM, "Fleshgrinder" <php@fleshgrinder.com> > escreveu: > > > Validating whether a number is within a closed or open interval is > > currently possible only via a construct like the following: > > > > ``` > > if (0 < $x && $x < 42) { > > echo 'x is in (0, 42)'; > > } > > > > if (0 <= $x && $x <= 42) { > > echo 'x is in [0, 42]'; > > } > > ``` > > > > It is not very readable and repetitive. It would be interesting to > > support a more mathematical notation for this: > > > > ``` > > if (0 < $x < 42) { > > echo 'x is in (0, 42)'; > > } > > > > if (0 <= $x <= 42) { > > echo 'x is in [0, 42]'; > > } > > ``` > > > > Richard, I'd be a +1 on this. I dislike having the double comparison all over checking for bounds, and have for quite a while. Akin to what David brought up, https://3v4l.org/7MvlB. It seems the requested syntax is not valid in any PHP version testable here. I can't speak to the complexities of implementing something like that, but would find it useful. Of course, you'd have to worry about other conditions like ``` if (0 < $x > 20) ``` By worry about, I mean, should it be invalid syntax, or, should it be optimized to be 20 < $x? I'd say you'd have to maintain the gt/lt for chaining. Then I'd wonder about similar syntax to check if 2 variables are both greater than 0, but one greater/equal to the other: ``` if (0 < $x <= $y) ``` -- Dave

« previous php.internals (#96748) next »