Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81634
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain seld.be designates 74.125.82.45 as permitted sender)
Message-ID: <54CFCDA8.8070301@seld.be>
Date: Mon, 02 Feb 2015 19:19:04 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net, Dmitry Stogov <dmitry@zend.com>, 
 Stas Malyshev <smalyshev@sugarcrm.com>
References: <CA+9eiLuueVvYgT-fhCvzBSxzoDioinpc5Eok5OQtGDBG1FZM=w@mail.gmail.com> <CAEZPtU5G1T3mpvjL2U0zAoYUKs8xh6NqjZ+hv9Aeab0h=TRB4A@mail.gmail.com> <54CFC849.3080001@gmail.com>
In-Reply-To: <54CFC849.3080001@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] What do we need strict scalar type hints for?
From: j.boggiano@seld.be (Jordi Boggiano)

On 02/02/2015 18:56, Stanislav Malyshev wrote:
> Hi!
>
>> Keeping that in mind, the declare statement, as ugly as it may look,
>> could be actually a killer to finally get what both camps want but
>> never (and never will) manage to agree.
>
> I think having two conceptual frameworks in one language and having to
> deal with (and potentially maintain) code bases with mixed conceptual
> framework is a very bad idea. That would lead to a language
> fragmentation as strict code will become hard to combine with non-strict
> code within one application, and pretty soon people will start asking
> questions like "is this library written in strict-PHP or non-strict-PHP?
> ow, dang, we can't use it because we use the other one..."

Stas, I respectfully think you misunderstand the RFC.

I think one good way to make a parallel is to compare it to having 
error_reporting(0); or error_reporting(E_ALL); on top of every file.

The RFC as it stands would make type hints be silently coerced by 
default, so it would have "error reporting" disabled by default, but if 
you set the declare line you do the equivalent of enabling error 
reporting but *only for your calls and returns*.

Right now if you use a sloppy library for example that throws E_STRICT, 
and you have reporting enabled, you do have fragmentation and it sucks, 
for example:

// strict.php
include 'non-strict.php';
error_reporting(E_ALL);
foo();

// non-strict.php
error_reporting(0);
function foo() {
     echo UNDEFINED_CONSTANT_FTW;
}
foo();

This produces:

UNDEFINED_CONSTANT_FTW
Notice: Use of undefined constant UNDEFINED_CONSTANT_FTW - assumed 
'UNDEFINED_CONSTANT_FTW' in non-strict.php on line 5
UNDEFINED_CONSTANT_FTW

In this case the strict file by using a non-strict function gets 
warnings thrown, so the community has to encourage/force everyone to 
behave strictly in libraries otherwise their code does not integrate well.

On the other hand, with the type hints, every file chooses how they want 
to behave and since it is not an ini setting it can not be influenced by 
another file like in my example above. Consider this for example:

// strict.php
declare(strict_types=1);
include 'non-strict.php';
foo(10);

// non-strict.php
include 'strict2.php';
function foo(string $output) {
     echo $output.PHP_EOL;
}
foo(5);
strictFoo(5);

// strict2.php
declare(strict_types=1);
function strictFoo(string $output) {
     echo $output.PHP_EOL;
}

This results in:

5 // output of foo from non-strict context
5 // output of strictFoo from non-strict context
Catchable fatal error: foo() expects parameter 1 to be string, integer 
given // failure of foo from strict context

So we see that the non-strict code works just fine on it's own, 5 gets 
coerced to string, no matter if it's calling strict libraries or 
non-strict ones, since it is itself non-strict. The strictness of others 
does not influence non-strict code and everyone integrates very well 
together.

When strict code calls non-strict code, they get errors if they pass 
invalid params, but that is what they want since they asked to be 
strict, so they get full on error reporting/static analysis of their 
code, but do not push it on the whole ecosystem.

Cheers

-- 
Jordi Boggiano
@seldaek - http://nelm.io/jordi