Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81636
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2AABD912-C2A3-4877-8B40-8E391B2BE45F@ajf.me>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me>
	<B0C5801F-7D46-4CB0-9B2E-AF18C44DAF14@ajf.me>
	<CA+9eiLtPVoDYT71fYrZfxPk6a_m7ErFd2w8UBvu9ZeTEbnm4kA@mail.gmail.com>
	<1E54E93F-8CE1-469F-BE1F-DD2F1DF76E39@ajf.me>
	<CA+9eiLv3YUdvvo7NbkMOoJEb4eVUyoHEYzoAPweJp3FXVfFNMQ@mail.gmail.com>
	<5175DE01-ADC9-4A0B-8343-820C53B30054@ajf.me>
	<CA+9eiLv+FCqiEmaM-NjGtMnpxyYb+x7zgrR5pneJmZowauDYBA@mail.gmail.com>
	<2AABD912-C2A3-4877-8B40-8E391B2BE45F@ajf.me>
Date: Mon, 2 Feb 2015 21:23:59 +0200
Message-ID: <CALW=WEC2-99y-dJ8MFcHG91+QSz74G-_L1iKWcwfMNsBopBY+w@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Dmitry Stogov <dmitry@zend.com>, PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: ua.san.alex@gmail.com ("S.A.N")

2015-02-02 21:12 GMT+02:00 Andrea Faulds <ajf@ajf.me>:
> Hi Dmitry,
>
>> On 2 Feb 2015, at 18:22, Dmitry Stogov <dmitry@zend.com> wrote:
>>
>> So, one of the advantages of strict type hinting is the ability to catch=
 potential errors.
>> For example when we pass 67 to setBody(string $message).
>
> Yes, that sort of thing is easily caught by strict type checks. They=E2=
=80=99re also able to catch things that are sometimes okay for weak hints, =
sometimes not. For example, some *but not all* strings are accepted for int=
eger and float parameters, and some *but not all* floats are accepted for i=
nteger parameters. Strict checks make this much simpler and not dependant o=
n the value: either some type is accepted, or it isn=E2=80=99t.
>
> Because of that, strict types can actually be effectively analysed ahead-=
of-time by static analysers, IDEs and so on, and so you can catch some type=
s of errors while editing your code, without even needing to run it. This i=
s quite a powerful feature. Nikita might have more to say on that.
>
> Thanks.
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Strict type checking, has its advantages.

We all external data convert to native PHP types.
The database we use option MYSQLI_OPT_INT_AND_FLOAT_NATIVE.
Inputs are validated and converted to native PHP types.
In Redis data are stored as serialize string.

In our API we may require strict adherence to type because the integer
as strings $id =3D "123" to impossible, i need catch these as logical
error.

But I also fully endorse, cast without loss of accuracy, because it
gives you more options and less of a problem for those who do not have
the conversion of external data.

Not to discuss endlessly two options, it is reasonable send to voting
the Strict type checking, voting will be fail :), then will be easier
to discuss technical issues as do korektno cast without losing data,
good luck!