Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59029
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAJWj5+HSGK80EDzBN2EW9teWf7xVS2gMwQFvMJSgWGmEgkKSJw@mail.gmail.com>
References: <CAJWj5+EwBpeMV__6SN7NbzQ0y4=RDGyg_HueU4N4AZz3Kb=CRQ@mail.gmail.com>
 <CADyq6sL2zbnqcYLpc7UrctPqdK+5TYztytKCxjdVUqUidsRN2g@mail.gmail.com>
 <A633CF2D7C7BED41B41F1E64F25507B806A48BEC0C@MAILR001.mail.lan>
 <CAJWj5+Eg5h7p=o5JRxw8gsRsT_LGGadMbNUqx5RxzRPif6u+Dw@mail.gmail.com>
 <CAJWj5+EfPh7oFq3NRH8iDSwU8kzhYQQfWByrbNHZO5dFdDQWGQ@mail.gmail.com>
 <CAJzDObfdw=V_Fy0ium9iqKM=U-9qVmCXfsZdb3Hdn34Zwk246g@mail.gmail.com> <CAJWj5+HSGK80EDzBN2EW9teWf7xVS2gMwQFvMJSgWGmEgkKSJw@mail.gmail.com>
Date: Mon, 19 Mar 2012 08:10:49 +0100
Message-ID: <CAMyk_AY6-viPrmhj1zazxawXG4WW_GWQuQm=64avaQ_BaVWNCg@mail.gmail.com>
To: Simon Schick <simonsimcity@googlemail.com>
Cc: Adam Jon Richardson <adamjonr@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf303b3c8743ffcc04bb934330
Subject: Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
From: linepogl@gmail.com (Lazare Inepologlou)

--20cf303b3c8743ffcc04bb934330
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Simon,

> in_array("123abc", array(3, 7, 123, 28)) =3D=3D=3D true

This is a pointless example, because the first argument of in_array is of
type "mixed" and not "int". So, this may cause many headaches, but it is
irrelevant to the discussion about scalar type hints.


Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel


2012/3/19 Simon Schick <simonsimcity@googlemail.com>

> 2012/3/18 Adam Jon Richardson <adamjonr@gmail.com>:
> > On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick
> > <simonsimcity@googlemail.com>wrote:
> >
> >>
> >> Hi, All
> >>
> >> Just to add an example why I want a more strictly type-check here as
> >> we have in the current type-juggling:
> >>
> >>
> http://www.brandonsavage.net/an-xss-vulerability-in-the-making/?utm_sourc=
e=3Drss&utm_medium=3Drss&utm_campaign=3Dan-xss-vulerability-in-the-making
> >
> >
> > I see the example given as one of poor validation, not a reason for mor=
e
> > strict type checking in a dynamic, weakly typed language.
> >
> > One could:
> >
> > - use a regex
> > - setting the third argument (strict comparison) of in_array() to true
> -OR-
> > looping through the array and checking equivalence with =3D=3D=3D
> > - ensure the type juggled value (the integer form) was returned and use=
d
> > rather than using the original string
> >
> > I actually like the conversation on scalar type hinting, and I've even
> > offered some ideas for integrating a form of it, too. However, poor inp=
ut
> > validation is not one of the reasons that I would use to justify its
> > inclusion. The goal of proper input validation should be to account for
> > page requests that include invalid data and provide appropriate feedbac=
k
> > within the natural flow of the application. Erring out when calling a
> more
> > strongly typed function at runtime does not provide this type of
> > application flow.
> >
> > Adam
>
> Hi, Adam
>
> I totally agree that type-hinting should not cover what the programmer
> should do for validating the given input ...
> But I just wanted to point out that this is something the author (and
> I) would never expect to happen ...
>
> in_array("123abc", array(3, 7, 123, 28)) =3D=3D=3D true
>
> But that's another thing :)
> I just wanted to point out that I don't want to have the string
> "123abc" accepted as an integer :)
>
> Anyways ... This thread should be a discussion about the whole
> concept, not the details.
> Sorry for getting off-context here.
>
> Bye
> Simon
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--20cf303b3c8743ffcc04bb934330--