Re: [RFC] Scalar Type Hints v0.2
| From: | Andrea Faulds | Date: | Mon, 02 Feb 2015 08:41:09 +0000 |
| Subject: | Re: [RFC] Scalar Type Hints v0.2 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-81562@lists.php.net to get a copy of this message | ||
Hi Dmitry,
> On 2 Feb 2015, at 07:02, Dmitry Stogov <dmitry@zend.com> wrote:
>
> As I already told, in my opinion, version 0.1 was the perfect solution that
> fit into PHP semantic very well.
I don't like the original. Weak types work to a degree, but they don't fulfill the use
case of a lot of developers, and consequently the RFC wasn't too popular outside internals.
> declare(strict_types=1); - 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.
> From 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 declare 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 types 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 code 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 for ints and floats can
prevent nastier errors later (float out of int range, or 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 and no strict
solution. Regardless of its merits, a large portion of the community is in favour of a
strictly-typed solution. There are also a lot of people who are in favour of weak typing. So, this
RFC tries to make a compromise.
Thanks.
--
Andrea Faulds
http://ajf.me/