On Thu, Feb 26, 2015 at 12:24 PM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>
> On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei <kont...@beberlei.de>
> wrote:
>
>>
>>
>> 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.
>>
>
> 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.
> 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.
>
> Thanks. Dmitry.
>
>
>>
>>
>>>
>>> Thanks. Dmitry.
>>>
>>>
>>>
>>
>
