Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69231
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 157.55.2.27 as permitted sender)
Message-ID: <DUB403-EAS1928C73C2B4F675744EC950E2210@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
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> <BLU0-SMTP4653FE63F45B66EB7C33532E2200@phx.gbl> <CAPwsocERwgXv4K0ROsPOSSrtDjqgbDwFuoT80=eeVZsW7-38jA@mail.gmail.com> <DUB406-EAS396583527048382A5C7B68AE2200@phx.gbl> <CAGrsWWJ9L0Jj+dGdx1i5qR+G6vQEt_bW5jiFYWxrjUh1k3OwjA@mail.gmail.com> <CAPwsocGJ5=1Loks3NDUt6Pd-o089c5JRvqwRFTzPGgPn4gkFGw@mail.gmail.com>
MIME-Version: 1.0 (1.0)
In-Reply-To: <CAPwsocGJ5=1Loks3NDUt6Pd-o089c5JRvqwRFTzPGgPn4gkFGw@mail.gmail.com>
Date: Thu, 19 Sep 2013 12:48:41 +0200
To: Leigh <leight@gmail.com>
CC: William Bartlett <william.a.bartlett@gmail.com>, Developers List PHP
 Mailing <internals@lists.php.net>
Subject: Re: [PHP-DEV] Re: Allowing is_* functions to accept multiple parameters
From: bobwei9@hotmail.com (Bob Weinand)

> Am 19.09.2013 um 11:10 schrieb "Leigh" <leight@gmail.com>:
>=20
> On 19 September 2013 03:20, William Bartlett
> <william.a.bartlett@gmail.com> wrote:
>> I would argue that LTR support is also inconsistent / not desired.
>>=20
>> If I wrote:
>>=20
>> $i =3D 0;
>> is_three($i =3D $i + 1, $i =3D $i + 1, $i =3D $i + 1);
>>=20
>> I would certainly expect is_three to return false, but I would also expec=
t
>> $i to contain three.  php doesn't normally evaluate arguments lazily, it
>> would be weird for that behavior to suddenly crop up.  users who want laz=
y
>> evaluation can write it the traditional way (with &&).
>=20
> I think there has been some misunderstanding of my intention here
> (maybe I communicated it badly) - Originally I was pretty confused
> when reading Bobs response as it was way beyond the scope of what I
> was proposing.
>=20
> When I say parameters evaluated LTR / boolean short-curcuit evaluation
> I mean it like this:
>=20
> $i =3D 1;
> $f =3D 1.1;
>=20
> is_int($i, $f, $i, $i) =3D> is_int(1) && is_int(1.1) && is_int(1) && is_in=
t(1)
>=20
> is_int($i++, $f++, $i++, $i++) =3D>  is_int(1) && is_int(1.1) &&
> is_int(2) && is_int(3)
>=20
> $i =3D=3D 4;
> $f =3D=3D 2.1;
>=20
> Internally, processing will stop at the is_int(1.1) and not bother
> continuing to check the types of further arguments.
>=20
> I did not mean:
>=20
> is_int($i++, $f++, $i++, $i++) =3D> is_int($i++) && is_int($f++) &&
> is_int($i++) && is_int($i++)
>=20
> As Bob said, this would take some pretty nuts opcode processing, and
> is completely not worth the effort involved. I may have emphasised a
> parallel with isset() a bit too much, however isset() cannot take
> expressions as input.
>=20
> I was never intending to try and evaluate parameters as they were
> passed and jump over subsequent evaluations. Standard function call
> semantics would still apply. I hope that people find that less
> confusing / unexpected.

Well, then I misunderstood what you meant.

Then the idea is acceptable. Not sure if we need this as it is very easily p=
ossible with an one-liner in userspace code.

I'm +- 0 on this.

Bob Weinand=