Am 18.9.2013 um 18:09 schrieb Leigh <lei...@gmail.com>: > On 18 September 2013 14:50, Sean Coates <s...@seancoates.com> wrote: >> i.e. is_null($a, $b, $c) would be the same as is_null($a) && is_null($b) >> && is_null($c) >> >> Note that this would not be semantically equivalent in this form, even if >> `is_null()` did accept multiple parameters, because of the short-circuiting >> with `&&`: > > See below. > > On 18 September 2013 15:53, Patrick ALLAERT <patrickalla...@php.net> wrote: >> 2013/9/18 Chris London <m...@chrislondon.co>: >>> I like the naming convention of are_*. For me personally it isn't directly >>> intuitive that the multiple parameters of is_* would be compared with an && >>> and not an ||. >> >> isset() already operates that way, keeping "is_" and implementing it >> as originally proposed by Leigh would, at least, be consistent. > > Indeed, my proposal was to mimic short circuiting as isset() does it, > evaluating LTR and returning false at the earliest opportunity.
At least, from a technical point, evaluating LTR would require to change the engine (would be some more complex change as it would require to switch between contexts and being able to execute the ZEND_SEND_VAL opcodes one by one (evaluate first argument and execute until next ZEND_SEND_VAL, and if one doesn't match the conditions, jump to the end of the sending args) etc.) Just have a look at the complicated opcodes, just for isset: http://3v4l.org/l3Z4l/vld And now do something like this for real functions (e.g. not a language construct) at run-time, because we'd have to do the function lookup at run-time (just because the name of the function might be unknown at compile time thanks to $var = "func"; $var();) The other alternative here is (like isset), just changing it into a language construct. (which I consider also suboptimal, as it disallows still things like $var = "is_*"; $var($arg1, $arg2, $arg3);). So, I am basically -1 on this, as this a) requires some deep engine change in the opcodes' handling flow or needs a change of language parser (well, if someone could provide a nice patch which implements this in a nice way, I'm in favor of this) and b) without LTR it effectively needs to evaluate everything, what would be a performance drop as opposed to the current (encouraged) method of just and'ing all the is_* calls. Then you also just could do in userspace code (with an one-liner): function are_int (...$args) { return count($args) == count(array_filter("is_int", $args)); } So: tl;dr: only in favour if technically not too complicated and doesn't have the restrictions of a typical language construct. Else: -1. Bob Weinand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
