On Mon, 16 Mar 2015 14:33:00 +0300, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:

Hi Derick,

On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans <der...@php.net> wrote:

To be frank, I don't think "I don't like this" is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the "declare" *syntax*, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
*best* bet, I can only vote "yes".


Are you sure on your bet?

lib.php:
<?php
        declare(strict_types = 1);
        function foo(int $a) {
        // no function call here
        }
?>
The declare here does just nothing.

a.php:
<?php
        require "lib.php";
        foo("123"); // will work
?>

b.php:
<?php
        declare(strict_types = 1);
        require "lib.php";
        foo("123"); // will give an error
?>

This behavior is unacceptable.
Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
work as it should. Otherwise, all kinds of unexpected for lib.php and it's
users may happen.

When called from a.php, foo() will get and int(123), this is exactly what is expected. Author of a.php acknowledges that all arguments in fcalls from this file will be converted to appropriate types, this is basically how all our internal functions work currently and it's perfectly acceptable. But if you don't want this kind of type juggling then you opt-in strict types. This is basically as easy as it gets, I don't see any way to make it simpler. There's nothing to evolve in this RFC, it covers pretty much everything and the idea of allowing for caller to make a decision is, in my opinion, a great win in this situation.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to