Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83224
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)
Message-ID: <54E61770.5040500@lsces.co.uk>
Date: Thu, 19 Feb 2015 17:03:44 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <011801d04a07$83ab1c00$8b015400$@php.net>	<CABDNdAFQsbo-A-gijPCwYDOf3ts-yKpP0tAL--WUaLU26GB-AQ@mail.gmail.com>	<016f01d04a3a$e9183220$bb489660$@php.net>	<CAESVnVoM7YbmXA8hTG1O66j+6YX3Xx2Q3uj_F=TPjHA4ws=8JA@mail.gmail.com>	<d8031ce52e9965c789887e8f7b687a4e@mail.gmail.com>	<CAESVnVpA+M6iv_zbDmKTEF8Q1zKjwnbi1ucc=UyuUyRr+X+U3w@mail.gmail.com>	<022801d04ab1$4a0c47d0$de24d770$@php.net>	<1913e09d7f52541901d8574d2080a63f@mail.gmail.com>	<CAAyV7nFD=BQ5dBYiKzhbOKTomKmWvruTnb=R_n9mYB-Lz1P9pg@mail.gmail.com>	<7a5d96b34b98ec1f3ee17be7fa6a1e81@mail.gmail.com>	<CAPhkiZxpYbaPN1370_HFTVnBA=Jg-rU8DrB2P+2dmRcJfGWPtw@mail.gmail.com>	<2CBDEB67-3DE3-437D-9AF3-0E6A92027244@zend.com> <CAPhkiZwcD3h42=9eak4uP9n2GBE=v0LVP6Ncq9Oz7L91dJ5y5w@mail.gmail.com> <4cc0c81c7199a452534bb8edcdb19914@mail.gmail.com> <54E589F6.9030002@garfieldtech.com> <d62afd01c97a2d00466ac88579fa861c@mail.gmail.com> <54E5B9DD.6080607@lsces.co.uk> <044201d04c42$277a8dc0$766fa940$@php.net>
In-Reply-To: <044201d04c42$277a8dc0$766fa940$@php.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: lester@lsces.co.uk (Lester Caine)

On 19/02/15 12:47, François Laupretre wrote:
> I didn't add restrictions specific to number representation in the draft ruleset yet, becausen while I think that's an important point, I didn't have time to study it in depth.
> 
> I know you're an expert on this as you continuously (rightly) raised the point.
> 
> So, can you elaborate on this and send me or, better, publish on the list the detailed set of changes you suggest, including 32 bit vs 64 bit concerns if they fit. Today, conversion restrictions are rather limited as floats which don't fit in int give 0, and int to float is considered as always possible. I mean that must be technically incorrect, while unnoticed in the vast majority of cases.
> 
> So can you write a consistent set of changes you would introduce ?

François ... My main interest in this over the years has been while
trying to port data between different engines, and that includes porting
legacy data from older systems such as dbase some of which originates
from 8 bit processor days.

One area that overlays the general discussion is the simple size of a
scalar value, and this just mirrors the number of bytes used to store
it. I1, I2, I4 and I8, but a more general validation facility on top of
'integer' would be a simple range.

decimal or numeric and float may get lumped together, but integer is a
much better base for decimal/numeric since it is lossless and simply
moves the position of the decimal point. Storage only requires an
integer of the appropriate size for the number of digits.

float is another miss used definition since it normally only allows for
32 bits of data, while double expands that to 64 bits. So once again the
platform may affect how these values are processed.

Pierre - You may think that the size   of integer is irrelevant in the
discussion on providing a strict type use of it, but in practice it is
somewhat important if the codebase you are creating is only 32bit but
all the data being handled is 64bit.

-- 
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