On Thu, 27 May 2010, Richard Quadling wrote: > On 27 May 2010 12:14, Zeev Suraski <z...@zend.com> wrote: > > BTW - even if strict type checking was implemented, do you truly think > > people won't simply cast their inputs to make PHP shutup about "42" not > > being a valid int? Let me assure you, they would. You'd gain nothing - as > > a matter of fact you'd lose out a bit since "abc" strings or arrays will > > happily cast into (int), while with our proposed solution - they won't. > > But it would be the user making that choice though. Rather than the > developer having to handle the incorrectly typed value. > > As I see it, it is no difference than interfaces. > > A class with interface X has to implement whatever methods interface X > declares. Failure to do so results in fatal errors. And rightly so. > > A function with prototype (int $a, bool $b, string $c) has to be > supplied the correctly typed data to work. Why is that so wrong?
It's exactly correct. Function declarations are a contract, just like interface specifications. Not a "let's pass some random stuff past customs to see if it works". Having this, in combination with the "numeric" (to allow both int and floats) and "scalar" (to just ignore things mostly) is the best possible solution. Adding casting typehints like "(int)" is something I could live with though. > In any decent course regarding defensive programming, we are told to > filter input and escape output. One easy way of filtering input is to > cast and verify. The filter extension is used with the sanitizing filters, will actually not return a string but the correct type as well. So that's even better to have strict typehints, because you catch filter errors too. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
