Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81562
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <B0C5801F-7D46-4CB0-9B2E-AF18C44DAF14@ajf.me> <CA+9eiLtPVoDYT71fYrZfxPk6a_m7ErFd2w8UBvu9ZeTEbnm4kA@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CA+9eiLtPVoDYT71fYrZfxPk6a_m7ErFd2w8UBvu9ZeTEbnm4kA@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <1E54E93F-8CE1-469F-BE1F-DD2F1DF76E39@ajf.me>
Cc: PHP Internals List <internals@lists.php.net>
Date: Mon, 2 Feb 2015 08:41:09 +0000
To: Dmitry Stogov <dmitry@zend.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: ajf@ajf.me (Andrea Faulds)

Hi Dmitry,

> On 2 Feb 2015, at 07:02, Dmitry Stogov <dmitry@zend.com> wrote:
>=20
> As I already told, in my opinion, version 0.1 was the perfect solution tha=
t
> fit into PHP semantic very well.

I don't like the original. Weak types work to a degree, but they don't fulfi=
ll the use case of a lot of developers, and consequently the RFC wasn't too p=
opular outside internals.

> declare(strict_types=3D1); - is really weird solution.

It is unusual, that is true. But it has some benefits.

> It changes type hinting behavior per file scope, so, just to try strict
> type hinting in a big project, people will have to change every single PHP=

> file.
> =46rom the RFC text, I didn't completely understand, if declare() affects
> call site or declaration.

Ah, my bad. It affects function calls and return statements within the decla=
re block, or remainder of the file if there's no declare block. So parameter=
 types are checked using the mode chosen by the calling code, while return t=
ypes are checked using the mode chosen by the called code.

> Will we able to call the same function using weak
> type hinting from on file and with strict from the other?

Yes, for the parameter type hints anyway. That means that strict and weak co=
de is interoperable without enforcing a model on each other.

> "The strict type checking mode also affects extension and built-in PHP
> functions", sin(1) - error !!!

That particular case is probably unpopular - although strict type hinting fo=
r ints and floats can prevent nastier errors later (float out of int range, o=
r silent loss of precision from int to float).

> Strict type hinting is not suitable for PHP by definition (as a weakly
> typed language), however, I see, it may be useful in some cases.
> I would prefer to have "weak" types at first, then think about introducing=

> ability to switch to "strict" type hinting in context of use-cases.

That'd be possible, but I fear that we'd just end up with weak typing only a=
nd no strict solution. Regardless of its merits, a large portion of the comm=
unity is in favour of a strictly-typed solution. There are also a lot of peo=
ple who are in favour of weak typing. So, this RFC tries to make a compromis=
e.

Thanks.

--
Andrea Faulds
http://ajf.me/=