Am 18.9.2013 um 18:09 schrieb Leigh <[email protected]>:
> On 18 September 2013 14:50, Sean Coates <[email protected]> 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 <[email protected]> wrote:
>> 2013/9/18 Chris London <[email protected]>:
>>> 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