Hi again,
> On 4 Feb 2015, at 11:15, Andrey Andreev <n...@devilix.net> wrote:
>
> On Wed, Feb 4, 2015 at 1:02 PM, Florian Margaine <flor...@margaine.com> wrote:
>> Hi Leigh,
>>
>> Le 4 févr. 2015 11:50, "Leigh" <lei...@gmail.com> a écrit :
>>>
>>> What was wrong with:
>>>
>>> function x(int $y, string $z) { // strict
>>> function x((int) $y, (string) $z) { // casting
>>>
>>> This was the best suggestion I've seen that covers the requirements of
>>> both camps, and is still very clear how data is going to be handled.
>>>
>>> Authors who want their APIs to adhered to strictly can do that,
>>> authors who want to accept anything and have it end up as their
>>> desired type can do that too.
>>
>> Because it is then the callee who decides, not the caller, whether or not
>> he wants strict typing.
>>
>
> ... and apparently, this is the root of all evil. :)
It’s not “the root of all evil". But the two-syntax approach has disadvantages
I’ve elaborated numerous times.
It shifts the choice to the callee, not the caller. This means existing
applications are broken if strict hints are added to existing libraries. It
means that programmers will have to deal with two different systems,
simultaneously, in the same file or function or method, because one API uses
(int) and the other uses int. It means that if the API author decides to have
weak types, you are prevented by the language from having the benefits of
strict typing, even if you want them. It also has a syntax issue: (int) looks
like an explicit cast, yet what is usually proposed doesn’t something similar.
There’s also the consistency issue in that we’d have to support real for
consistency with (real), since T_DOUBLE_CAST is a token. It means that internal
functions could now also use strict hints - or if they can’t, we have a
consistency issue. It means beginners, and people who don’t like strict types,
now have to deal with strict types in their code, despite PHP always having
been a weakly-typed, beginner-friendly language. And so on, and so forth.
The current RFC deliberately does not propose this because I think it causes
more problems then it solves.
> I am baffled by how the two-syntaxes suggestion is always so easily
> dismissed by that argument. I'd argue that most people who support the
> current proposal don't fully understand what declare(strict_type=1)
> really does.
Well, *I* understand what it does. I’ve used it. It worked really,
fantastically well… better than I expected it to. It provided benefits that the
two-syntax suggestion wouldn’t have. It provided benefits that just strict
hints wouldn’t have. It provided benefits that just weak hints wouldn’t have.
> As I've previously said - putting the caller in control
> (and really the caller, not in a per-file context) makes it a
> debugging tool, not support for strict typing.
What’s the difference between “per-file” and “really the caller”? The RFC
*does* allow you to use declare() blocks if you really want to.
Also, type hints are mostly a debugging tool anyway. They’re a tool for
catching errors early, and to enable better documentation. That’s all that they
do.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
