Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83891
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEPJdumxCVsRPFHj8Xy88=j-6CbUmrU=tbdEFY7F9W-GDGwJ0w@mail.gmail.com>
References: <CA+9eiLsDt9K+DNrnT3Dh7eMwOBCoaP_xgnjNtptu03P8JnmzwQ@mail.gmail.com>
	<CAEPJdunZpePBb1w6=AEZKxjj_7EZaPLGONkBr40q5=9fOXptpw@mail.gmail.com>
	<CA+9eiLuweW=_V8EgqJ40Rr-gXmVQLBnF4FB57AC9f_Z57A9Lww@mail.gmail.com>
	<CAEPJdun_vByOxO+R7SJJ77fXGExYAyY+vGz77fHNwt1sXE9z2w@mail.gmail.com>
	<CA+9eiLsb5Cbz=tVu0+bYoseEa5vbeP+Dr8H+c-+DMHr_X2XGcA@mail.gmail.com>
	<CAEPJdumxCVsRPFHj8Xy88=j-6CbUmrU=tbdEFY7F9W-GDGwJ0w@mail.gmail.com>
Date: Thu, 26 Feb 2015 16:07:19 +0400
Message-ID: <CA+9eiLvtQg=qywuFqfC9Qcegp30cxauGQamFzgff5Dw1vH3hMQ@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b86d990fa77a6050ffc972e
Subject: Re: [PHP-DEV] Strict typing and callback vs declare()
From: dmitry@zend.com (Dmitry Stogov)

--047d7b86d990fa77a6050ffc972e
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 26, 2015 at 2:34 PM, Benjamin Eberlei <kontakt@beberlei.de>
wrote:

>
>
> On Thu, Feb 26, 2015 at 12:24 PM, Dmitry Stogov <dmitry@zend.com> wrote:
>
>>
>>
>> On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei <kontakt@beberlei.de>
>> wrote:
>>
>>>
>>>
>>> On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov <dmitry@zend.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei <kontakt@beberlei.de>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov <dmitry@zend.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Anthony,
>>>>>>
>>>>>> What do you think about using a user level callback for strict type
>>>>>> checks
>>>>>> instead of declare(). It won't allow changing behavior per file, but
>>>>>> this
>>>>>> has its own cons and pros.
>>>>>>
>>>>>> <?php
>>>>>> set_strict_type_checker(function ($class_name, $function_nume,
>>>>>> $arg_num,
>>>>>> $expected_type, $value, $file, $line) {
>>>>>>   ...
>>>>>>   return false;
>>>>>> });
>>>>>> include("orig_index.php");
>>>>>> ?>
>>>>>>
>>>>>> If callback is not set, arguments are converted according to standard
>>>>>> rules, if set and returns false - fatal error or exception is thrown.
>>>>>>
>>>>>> The implementation should be simpler and more efficient than using
>>>>>> declare().
>>>>>>
>>>>>> Thanks. Dmitry.
>>>>>>
>>>>>
>>>>> This ruins portability with third party libraries completely.
>>>>>
>>>>
>>>> Not completely, because checker may be smart enough to return "true"
>>>> for third party files.
>>>>
>>>> <?php
>>>> set_strict_type_checker(function ($class_name, $function_nume,
>>>> $arg_num,$expected_type, $value, $file, $line) {
>>>>    if (!my_own_file($filename)) {
>>>>      return true;
>>>>    }
>>>>    ...
>>>>    return false;
>>>> });
>>>> include("index.php");
>>>> ?>
>>>>
>>>> And you won't have to modify each file in your project adding
>>>> declare(strict_types=1).
>>>>
>>>
>>> Yes, but you need a mechanism for each third party library to register
>>> their typechecker code and then build a generic type checker system using
>>> the right checks for the right library. This will produce really slow code
>>> considering it will trigger this on every argument.
>>>
>>
>> Only for strictly wrong arguments.
>>
>>
>>> Also i find declare(strict_types=1) is already adding another stack in
>>> my mind to think about, now having to think about every file/lirary having
>>> a different kind of validation makes it even more complicated.
>>>
>>
>> You 'll have to think about each file anyway. To add or not to add
>> declare(strict_types=1).
>>
>
> Yes, but It has only exactly one ruleset to keep in mind. With your
> approach the ruleset space is infinite. Much more complex.
>

I agree. It's more complex, but also more flexibly.
anyway, I just had an idea and posted it to discuss.


>
>
>> Callback would allow to care about strict type checks in one separate
>> place.
>> It's like to keep a screw key with every nut in your car instead of
>> keeping toolbox.
>>
>
>>
>>>
>>> Additionally it destroys the AOT compile benefit of static type hints,
>>> since you cannot compile code down to C again, because the
>>> conversion/validation is not necesarily deterministic.
>>>
>>
>> Oh god...
>> If you know the type of passed and expected argument at compile time,
>> strictness doesn't make any difference (you may only report a error at
>> compile time).
>> If you don't know type of passed or expected argument at compile time,
>> you'll have to check their equality at run-time anyway.
>>
>
> This is not my argument, just saying that what strict Types would allow
> (static analysis and AOT) is not possible when the static rules are not
> determinstic. This will lead to every pro static person to reject your
> approach. declare(strict_types=1) is about having a single, pre-determined,
> deterministic ruleset.
>

I heard it many time and many times replied with the same sentences as
above.
In my opinion, this argument is not true.
It's possible to do equally efficient static analyses and AOT with weak and
strict types.

For example:
<?php
function foo(int $a) {
}
$b = 1;
foo($b);
?>

At call site we know that $b is integer and foo() expects integer. so we
don't need to generate code for any checks

<?php
function foo(int $a) {
}
foo($b);
?>

At call site we know what foo() expects integer, but don't know type of $b.
Sp we have to check it at run-time.

<?php
function foo(int $a) {
}
$b = "1";
foo($b);
?>

Here we know both types and now that they are not the same.
With strict type hints we may generate a compile-time error message or a
code for run-time error message.
With weak type hints we will generate an unconditional call to run-type
conversion function e.g. convert_string_to_long();
If we know the value at compile-time we may also perform compile-time
conversion.

Thanks. Dmitry.


>
>
>>
>> Thanks. Dmitry.
>>
>>
>>>
>>>
>>>>
>>>> Thanks. Dmitry.
>>>>
>>>>
>>>>
>>>
>>
>

--047d7b86d990fa77a6050ffc972e--