> From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
>
> 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.
