On 19/03/16 05:20, Walter Parker wrote: >> C A Horte, the famous computer scientist, calls the introduction of nulls > into his type system (like how Java did it decades later) to be his Billion > dollar mistake. He did it for the mathematical elegance and didn't foresee > all of the null errors that would come. Nulls sound great in theory, in > practice they can be trouble.
If one is dealing with a single variable this statement may apply, and since everybody is trying to define the function of a single variable they are missing the bigger picture. When running a RELATIONAL database query, one is often combining the results of several tables, Joins can be defined to only include a result if the sub-record also exists, or ignore those fields if for that record the result does not apply. NULL is the CORRECT return for those fields, and isnull is the correct check to select a function that is used when that element of the result does not apply. One does not expect the database engine to replace those NULL values with acceptable typed default results. This is why many of the previous discussions on how to handle NULL have resulted in even more problems! NULL is a state of the variable and the 'error message' contained within each line of a result set. The argument goes on that NOT typing your variables is bad design, and for some places that is a correct statement, but as I have said many times, simply expecting the database result to be an integer is bad design since the value returned will also have a defined length. We know the problems that returning a BIGINT creates in PHP5, but simply trying to ensure 'integer' is 64bit internally produces different results where the database value is actually 8, 16 or 32 bits. And different results again on 32bit builds of PHP don't help! It's not unreasonable for a complex SQL query to produce different 'type' results for a column if the unions combine SMALLINT and INTEGER values, and in these cases a 'string' result ensures consistency, which PHP currently maps nicely, but which a strict type would baulk at. Personally I would be looking to ensure the database design was consistent, but we have 20+ years of data and originally the smallest data type was used to keep the record sizes down. Just how many different 'integer' fields do exist ... each with different rules. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
