On Thu, Feb 26, 2015 at 1:43 PM, Joe Watkins <pthre...@pthreads.org> wrote:
> > The implementation should be simpler and more efficient than using
> declare().
>
> This can't really be correct, if a call to
>
> function mine(int $one, double $two) {
>
> }
>
> results in three function calls then that's going to cost considerably.
>
No. The callback is going to be called only when expected and passed types
are different (e.g. passing "123" to int; or 1 to bool)
It must be relatively seldom.
>
> I don't like the idea of user function being called, but don't hate the
> idea of an internal
> API that allows an extension to implement a type system.
>
> It could be much simpler, like turning zend_verify_arg_type into a pointer
> to a function like
> we did with gc function.
>
> All of this is inferior to dual mode, in my opinion.
>
Implementing, strict types in extension is an option. but I think it won't
satisfy the strict camp.
User callback is a tool that doesn't change the mainstream language
semantic, but provides a way to analyze strict type inconsistencies.
Thanks. Dmitry.
>
> Cheers
> Joe
>
> On Thu, Feb 26, 2015 at 10:34 AM, 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.
>>
>
>
