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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
