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.
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.
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.
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.
Cheers
Joe
On Thu, Feb 26, 2015 at 10:34 AM, Benjamin Eberlei kontakt@beberlei.de
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.
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
JoeOn Thu, Feb 26, 2015 at 10:34 AM, Benjamin Eberlei kontakt@beberlei.de
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.
On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei kontakt@beberlei.de
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).
Thanks. Dmitry.
On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei kontakt@beberlei.de
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.
On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei kontakt@beberlei.de
wrote:
On Thu, Feb 26, 2015 at 1:34 PM, Benjamin Eberlei kontakt@beberlei.de
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).
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.
Thanks. Dmitry.
Thanks. Dmitry.
On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei kontakt@beberlei.de
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.
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.
On Thu, Feb 26, 2015 at 2:34 PM, Benjamin Eberlei kontakt@beberlei.de
wrote:
On Thu, Feb 26, 2015 at 2:09 PM, Benjamin Eberlei kontakt@beberlei.de
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.
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.
Currently the rule set is already 'infinite' since many libraries will
already be checking for their own conditions and verifying they have a
valid variable to start with is the first step. The nice thing about PHP
IS it's flexibility in the way one is not constrained by a single core
framework and the more I look at this, the more making PHP a little more
flexible makes sense. Being able to bolt in a validation system
appropriate to the library being used makes perfect sense, but I already
see that code in the libraries I use anyway. The problem with proper
validation is that it either needs the annotation RFC to allow
definition of all the rules or access to some other data model such as
the metadata of a database. Simply saying 'int' and then blocking all
valid forms of that value is only part of the process but providing a
mechanism that CAN be optimised for the target and which can be enhanced
via that target can only be an improvement on what is proposed so far.
And the title here is wrong - this is not restricted to 'strict' it
applies to all scalar type hinting/checking.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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().
It is too complex for what we need. The declare statement is as simple
as "use.." present as the top of the file, has to be checked just like
"use", no brainer for the users.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org