Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58997
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.188 cause and error)
Message-ID: <4F65A39D.1010103@lsces.co.uk>
Date: Sun, 18 Mar 2012 08:58:05 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Firefox/10.0.2 SeaMonkey/2.7.2
MIME-Version: 1.0
To: PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Data type coercion
From: lester@lsces.co.uk (Lester Caine)

I just though it was worth throwing in this link to the 'debate' on data type 
hints and casting ...
http://dyemanov.blogspot.co.uk/2011/07/data-type-coercion-vs-comparison-rules.html

While it goes back a little time wise, it flags the SQL standard which while 
that is not available to simply view on line ( standards should NOT be a 
commodity! ) a search for "Result of data type combinations" brings up a few 
other views on the 'problem'.

This is another of those areas where cross database working can produce some 
unexpected results, and while using databases with PHP is probably not the 
'norm', it does provide another target with which consistent type management can 
be compared. But having said that, MySQL probably fails to follow the standard 
anyway? In my own case, data from the database normally ends up being returned 
as strings but with validity checks having been carried out in the database 
engine, so further 'hinting' within PHP would tend to be a little redundant.

-- 
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//
Firebird - http://www.firebirdsql.org/index.php