Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81652
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: <54CFE324.1080103@lsces.co.uk>
Date: Mon, 02 Feb 2015 20:50: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: <CA+9eiLuueVvYgT-fhCvzBSxzoDioinpc5Eok5OQtGDBG1FZM=w@mail.gmail.com> <54CFD8B3.9080208@lsces.co.uk> <005101d03f25$08e157b0$1aa40710$@tutteli.ch>
In-Reply-To: <005101d03f25$08e157b0$1aa40710$@tutteli.ch>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: AW: [PHP-DEV] What do we need strict scalar type hints for?
From: lester@lsces.co.uk (Lester Caine)

On 02/02/15 20:15, Robert Stoll wrote:
> Nobody would stop you from implementing a utility class Money or likewise and providing a better error message instead of using int if PHP would be strict only (what is not proposed in the RFC anyway). You could also just omit the type hint, it is entirely up to you. 
The point here was that this is creating yet another set of rules that
only apply in some cases. Rather than perhaps looking at a more generic
solution that can be used in validation across all types.

> There are plenty of strongly typed languages out there which work very well without the mentioned lack of specific error messages for each individual use case.
Lived with that in the past ... having to convert everything TO some
common type before using it is just as irritating. PHP's lighter touch
especially where data is coming in mainly from a string based feed is
much nicer to work with.

> And btw. PHP is strict for array and class type hints as well  - of course you can also omit those type hints. 
Which are creating even more conflicts.

The ONE element that I am growing concerned about is a simple 64bit
BIGINT primary key which can be used as an array index. A strict integer
is heading towards some complex variable length data type, while for
probably 99.9% of database related BIGINT data it is a simple integer.
If third party libraries move towards a 'strict' style of working they
may not be efficient when used without that practice, or they may not
play nicely with other interfaces that have a different 'strict' view.
There are a growing number of low cost devices which are essentially 32
bit devices, but with 64 bit maths which is possibly incompatible with
the current 'strict' view of data within PHP.

-- 
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