Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83364
Return-Path: <padraic.brady@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 46036 invoked from network); 21 Feb 2015 00:07:45 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 21 Feb 2015 00:07:45 -0000
Authentication-Results: pb1.pair.com smtp.mail=padraic.brady@gmail.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=padraic.brady@gmail.com; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.177 as permitted sender)
X-PHP-List-Original-Sender: padraic.brady@gmail.com
X-Host-Fingerprint: 209.85.160.177 mail-yk0-f177.google.com  
Received: from [209.85.160.177] ([209.85.160.177:48174] helo=mail-yk0-f177.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 05/00-45394-F4CC7E45 for <internals@lists.php.net>; Fri, 20 Feb 2015 19:07:43 -0500
Received: by mail-yk0-f177.google.com with SMTP id 20so8690877yks.8
        for <internals@lists.php.net>; Fri, 20 Feb 2015 16:07:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        bh=FP6ZHxzI1Ev2+WITAcZFpND3tpsuIVfW5wAHzBsjZb4=;
        b=wE4zM1uDiqpG2h3UdJK+VD7HmfY1TVFHGBwyxaFz7vh00NxBpHt/HV2VAF1YSHbYOb
         ZCSo6Q7KeYcxnm9WAEy28OvDJokNk6QIauz1igtnf0kkp1xmpbv4+oxg4OSzxD7PKdxl
         zcB0h6sh8LzW3kNKOYO2OeaxdPs5SgU/Ykv8xBGzAiiyihSaMGdTUIuanVRgXsylNFa6
         pqFM3qnepzy0pC41VQPDqETMyruIK7veqqdBf84Y6hSLr4az16PNbUKW3a0GWtCHFErF
         KpzmJAnoX801mORqdJEIoA+pg1Qere/0JBMXopIm/JSGF0ZAwNDHqywEg2YGY+dx25/w
         0Hpw==
MIME-Version: 1.0
X-Received: by 10.170.199.137 with SMTP id q131mr168858yke.113.1424477260042;
 Fri, 20 Feb 2015 16:07:40 -0800 (PST)
Received: by 10.170.222.86 with HTTP; Fri, 20 Feb 2015 16:07:39 -0800 (PST)
In-Reply-To: <54E7C558.7030900@garfieldtech.com>
References: <CANUQDCiPP9=_=ZDX7prvCNdXvxZRs3Awq-FaLDDE5K-U3hXZRQ@mail.gmail.com>
	<54E7C558.7030900@garfieldtech.com>
Date: Sat, 21 Feb 2015 00:07:39 +0000
Message-ID: <CALwr1GmOnsB8O2yu+ri92u5XvF9a0UxdU2s7GVE03BQnpQPESQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][Discussion] In Operator
From: padraic.brady@gmail.com (=?UTF-8?Q?P=C3=A1draic_Brady?=)

On 20 February 2015 at 23:38, Larry Garfield <larry@garfieldtech.com> wrote=
:
> While I love the idea, strict type comparison for in would, in essence, b=
e a
> toe-dip into the scalar strict typing world (see other thread) that would=
 be
> very confusing.  Consider:
>
> if (3 in $_GET['filters']) { ... }
>
> That would always be false, because $_GET is always strings.  To make tha=
t
> work I'd need to first cast all of the elements in that array to ints...
> which I'm not actually sure how to do cleanly.

You need casting anyway if comparing raw GET/POST directly to any
integer as a decision point on whether to use the raw value, i.e. it's
unvalidated otherwise and could have been "1234<script>[...]".

Yes, I'm abusing your intentionally very simple example. There are
other cases away from user input where looser comparisons wouldn't
have the same potential issues with non-permanent type juggling. I
would be a huge fan of having it be strict since the above, while
clearly a simple example, has been problematic in the past for
validation routines and, as a security guy, I'm obsessed with that ;).
Also, on toe-dipping into strict typing, I think your opinion may be
slightly overweight towards that topic given recent RFC history - we
already have =3D=3D=3D as our toe in the water.

> I'd much rather we tighten up the rules around implicit casts generally, =
as
> discussed elsewhere, and then allow those "loose but not as loose as we h=
ave
> now" rules here.

I could work with that perhaps. RFCs of this type are in a bit of a
bind while we wait for scalar typehints/potential casting rules to be
finalized in some form. It also appears unlikely that "in" as the
operator name will pass muster if the context sensitive lexer RFC does
not pass, i.e. would break uses of in() as a method name.

Niklas, any chance you have considered a Plan B for the operator
naming? Mostly curious if these is already some alternative outside of
the field of langs I'm familiar with that might be acceptable.

Paddy

--
P=C3=A1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com