Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69205
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.87 as permitted sender)
Message-ID: <BLU0-SMTP4653FE63F45B66EB7C33532E2200@phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
In-Reply-To: <CAPwsocGm4s_rPWg3UuJvz3=d7qBwZxLZVXe7rdm-_mua=UfyfA@mail.gmail.com>
Date: Wed, 18 Sep 2013 19:50:36 +0200
CC: Developers List PHP Mailing <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <CAPwsocGni4kjJq9c5wr77ohPU+YX2=0O7EgahdH=p0=hH1H_fA@mail.gmail.com> <49D57F66323040FC9AE48244DAAF3771@gmail.com> <012B9378-3C3A-4169-96D3-3B57D6C7A82C@seancoates.com> <CAAjMSDNwmpFRpX4VTj-AoUYp2PWXioyQRE3o8eCvb8VzXsB9Hw@mail.gmail.com> <CACwt+JcwJQB6b8JpJAp6g67NKgUr9ebMRbGKH=aHLX7wk+2Rxw@mail.gmail.com> <CAPwsocGm4s_rPWg3UuJvz3=d7qBwZxLZVXe7rdm-_mua=UfyfA@mail.gmail.com>
To: Leigh <leight@gmail.com>
Subject: Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
From: bobwei9@hotmail.com (Bob Weinand)

Am 18.9.2013 um 18:09 schrieb Leigh <leight@gmail.com>:
> On 18 September 2013 14:50, Sean Coates <sean@seancoates.com> wrote:
>> i.e. is_null($a, $b, $c) would be the same as is_null($a) && =
is_null($b)
>> && is_null($c)
>>=20
>> 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 `&&`:
>=20
> See below.
>=20
> On 18 September 2013 15:53, Patrick ALLAERT <patrickallaert@php.net> =
wrote:
>> 2013/9/18 Chris London <me@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 ||.
>>=20
>> isset() already operates that way, keeping "is_" and implementing it
>> as originally proposed by Leigh would, at least, be consistent.
>=20
> 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 =3D "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 =3D "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) =3D=3D 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.=20

Bob Weinand=