Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91768
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
To: internals@lists.php.net
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <CADyq6sKRFA667RA8Uzcx8SZ9x+GMEvoiX8S7QqrfV-fh0qgrGg@mail.gmail.com>
 <CADyq6sJxUrTQu__mQv-649cyvg4htzG+VK5g400b5-Vrvs5+TQ@mail.gmail.com>
 <56EC69EF.1090003@fleshgrinder.com> <56ECCFCB.6090105@garfieldtech.com>
 <CAMPTd_CWxa7K50fSbYHOEcHvM62YcfcBtZ1Cr392UHkXPsay8g@mail.gmail.com>
Message-ID: <56ED2EA6.9080504@lsces.co.uk>
Date: Sat, 19 Mar 2016 10:49:10 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <CAMPTd_CWxa7K50fSbYHOEcHvM62YcfcBtZ1Cr392UHkXPsay8g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: lester@lsces.co.uk (Lester Caine)

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