Re: Scalar-type-hinting - which way is the best to go?

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_source=rss&utm_medium=rss&utm_campaign=an-xss-vulerability-in-the-making > > > I see the example given as one of poor validation, not a reason for more > 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 === > - ensure the type juggled value (the integer form) was returned and used > 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 input > 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 feedback > 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)) === 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