> From: Arvids Godjuks [mailto:[email protected]]
>
> Hello, i should point out that it is all unicorns and rainbows for building inernal apis and
> libraries. But in PHP you work with the world out there.
> And that means you process GET, POST, xml, json and bunch of other data, witch comes to you as
> text. Even db requests usually retirn text even with numeric data. It all works great and easy now
> because PHP handles the conversion, just have to check if the data is correct. So what will happen
> with strict typing if i define an int and external data gives me a numeric string? Or some ass tries
> to send me an array. Code just breaks into fatal error? You can build a safe code that handles that,
> but if you write jist a bunch of pretty strait forward scripts and you don't need all that
> complex code with a framework type handling, sanitizing and so on.
>
> Sure, inernal apis would be strictier and so on, but hell even now i think it will make so much
> pain to make sure to convert all the data and params - every db row, get params, xml data, etc. Duck
> typing is what makes php a great tool for web development. And type hinting should be weak, trying
> to convert data if is a now brainer and fail on real mistakes, like now honting that you expect an
> array and a string is passed. But expecting an int and passing a string containing int number should
> go smooth
Nobody really wants typing as strict as what you are implying above. Even C++ (some of the strictest
typing available) does implicit conversions where appropriate. All of the following should be
perfectly valid:
(function(integer $n){})('1');
(function(string $s){})(1);
(function(float $f){})(1);
(function(integer $n){})(1.0);
(function(string $s){})(1);
(function(boolean $b){})($foo);
(function(string $s){})($some_object_with_a___tostring_magic_method);
As far as unconvertible inputs, here's the thing; most logic needs to know roughly what it is
working with and only works with a limited range of valid inputs. For example, consider substr(),
which will never make any sense unless you pass a string and an integer. If you try to call
substr('foo', 'bar') it's going to have to fail, the only question is at
what level and how. So called "strict typing" doesn't cause new errors, it gives
structure to a ubiquitous set of existing error conditions.
John Crenshaw
Priacta, Inc.