> > Unless you are aware of the type of your variables and the data they
> > contain as you write your applications, you are only inviting trouble
> > anyway. Yes,
>
> If you think so, you should use statically typed languages, why invite
> trouble from the start?
It is not inviting trouble. In fact it is a good way of avoiding trouble. If
anything it only encourages discipline when writing code and I have yet to
find a programmer who thinks that is a bad thing.
It is one of the things that often annoys me with php functions is that they
do everything they can to avoid failing. While this saves me from looking at
a E_FATAL error, it also subjects my data to changes that are I cannot know
and often differ from function to function.
What this encourages is careless coding standards, where programmers just
assume that PHP will look after them, which is no doubt one of the reasons
behind the popular myth that PHP encourages sloppy programming.
In the days of PHP 4 there was not much of a choice. The best solution was to
either avoid failing at all cost or return a false value to prevent data from
being twisted. Now we have exceptions which makes failing quickly to prevent
mistakes easy and useful.
Here is a small example of how data can be twisted:
function incr($number)
{
static $total = 0;
$total += $number;
return $total;
}
$n1 = 2; $n2 = '1';
incr($n1);
$n3 = incr($n2);
print $n3;
$n2 is a string value of the number one. What happens if, during a more
complex computation an incorrect value is store to $n2, lets say an
alphabetic character?
The value would be interpreted as a zero and the result would be wrong.
This is just a small example, but hidden among 30,000 lines of code, looking
for it would definitely ruin my day.
> Maybe you should write your code differently, so that you shouldn't
> check it so often.
I could try that. But then again I have found that the way that I write my
code has produced quality work for which I have been rewarded with satisfied
users. So obviously I am doing something right.
One thing that I will not do is be arrogant enough to assume that because
someone does something differently from me it has to be wrong. If anything is
sure, is that people will use your code for things that you never considered
(note that this is not a bad thing).
> I just checked in Zend Framework source - which is
> not a small body of code - is_integer is used in capacity you want to
> use typehints (i.e. "this type or error out") only twice, and in both
> cases I'm not sure it's needed. is_float is not used even once, and
> is_string I found used only three times in this way, all IMHO
> unnecessary since simple (string) would work.
Right... So your argument is that because you guys did not do it with the Zend
Framework, none of us should do it?
> It could make at least minimal sense to make it converting - but making
> it type-strict just makes your application blow up in different, less
> expected, places without actually saving you any time on coding.
Actually it makes less sense to have type hinting as sort of a hidden way to
cast values. Whenever execute operations somewhere the developer cannot see
it, you risk blind-sighting him because one minute he expects only X to
happen and suddenly (usually upon discovering a bug, potentially in
production use) he notices that both X and Y happened.
Tomi Kaistila
PHP Developer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
