On Thu, Feb 26, 2015 at 11:56 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>
> On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei <kont...@beberlei.de>
> wrote:
>
>>
>>
>> On Thu, Feb 26, 2015 at 11:10 AM, Dmitry Stogov <dmi...@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.
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.
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.
>
> Thanks. Dmitry.
>
>
>
