Re: [PHP-DEV] strict_types should be renamed raise_type_error. WAS: About declare(strict_types = 1)
On Mar 18, 2015 6:42 PM, Patrick ALLAERT patrickalla...@php.net wrote: Le lun. 16 mars 2015 à 21:34, Matthew Leverton lever...@gmail.com a écrit : (Although the irony of using =1 instead of =true isn't lost on me!) Yes, I mentioned[1] that funny aspect earlier. 0 or 1 is explicitly required in order to update the boolean behind it while true/false generates a fatal error with strict_types declaration must have 0 or 1 as its value. [1] https://twitter.com/patrick_allaert/status/568167144363560961 Ok. You do not like this RFC, we get it. Now, what's about actually being constructive and if you find bug (and please under the context of this RFC and how it works) please report a bug so it can be fixed.
Re: [PHP-DEV] strict_types should be renamed raise_type_error. WAS: About declare(strict_types = 1)
Le lun. 16 mars 2015 à 21:34, Matthew Leverton lever...@gmail.com a écrit : (Although the irony of using =1 instead of =true isn't lost on me!) Yes, I mentioned[1] that funny aspect earlier. 0 or 1 is explicitly required in order to update the boolean behind it while true/false generates a fatal error with strict_types declaration must have 0 or 1 as its value. [1] https://twitter.com/patrick_allaert/status/568167144363560961
Re: [PHP-DEV] strict_types should be renamed raise_type_error. WAS: About declare(strict_types = 1)
On Mon, Mar 16, 2015 at 8:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
I think this is important, but not many people realize the importance.
Therefore I created this as a new thread at the last minutes of vote.
On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz den...@birkholz.biz
wrote:
Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
lib.php
?php
declare(strict_types = 1);
function add(int $a, int $b) {
}
?php
add($_GET['a'], $_GET['b']);
that means, I need to add a lots of (int) while I try to call a
function in a library which is not written by myself.
that is not right and has been discussed a thousand times over.
The declare changes the rules only for function calls in the file it is
declared in.
so:
lib.php:
?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
?php
require lib.php;
foo(123); // will work
?
?php
declare(strict_types = 1);
require lib.php;
foo(123); // will give an error
?
If this kind of behavior is allowed, why strict mode is called strict?
It's not
strict at all if mode could be overridden.
strict_mode is just controlling errors, then it should be named as error
controlling directive and raise E_WARNING/E_TYPE or whatever.
Even if what its controlling is error that can be overridden by caller, yet
calling it strict_types is not correct. Proper name would be something
like raise_type_error.
Let's see how it looks if strict_types is renamed to raise_type_error
?php
declare(raise_type_error = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
?php
require lib.php;
foo(123); // will work
?
?php
declare(raise_type_error = 1);
require lib.php;
foo(123); // will give an error
?
Is everyone feel OK with this??
There are other things I would like to mention, but this would be enough
to change decision hopefully.
Regards,
P.S. If we are going to introduce strict types for basic types, what we
really need is type affinity for inputs. e.g. $_GET/$_POST/$_COOKIE.
https://www.sqlite.org/datatype3.html
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hello,
this would make more sense than strict types, which is a bad name
anyways (as I already mentioned in some other email) - because the
concept of non-week typing is usually called strongly typed in any
other language I can think of. Does PHP have to be a special
snowflake?
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strict_types should be renamed raise_type_error. WAS: About declare(strict_types = 1)
On Mon, Mar 16, 2015 at 2:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, I think this is important, but not many people realize the importance. Therefore I created this as a new thread at the last minutes of vote. ... strict_mode is just controlling errors, then it should be named as error controlling directive and raise E_WARNING/E_TYPE or whatever. Even if what its controlling is error that can be overridden by caller, yet calling it strict_types is not correct. Proper name would be something like raise_type_error. Let's see how it looks if strict_types is renamed to raise_type_error ... ?php declare(raise_type_error = 1); require lib.php; foo(123); // will give an error ? I agree that the name doesn't by itself explain the feature, but how could it possibly? You'd end up with something like: declare(raise_type_errors_on_parameter_mismatches_when_calling_functions_from_this_file_regardless_of_where_the_functions_are_defined_and_what_the_setting_is_in_other_files=1); I don't think your suggestion explains the feature any better than strict_types. (Although the irony of using =1 instead of =true isn't lost on me!) -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strict_types should be renamed raise_type_error. WAS: About declare(strict_types = 1)
Hi Matthew and all,
On Tue, Mar 17, 2015 at 5:34 AM, Matthew Leverton lever...@gmail.com
wrote:
On Mon, Mar 16, 2015 at 2:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
I think this is important, but not many people realize the importance.
Therefore I created this as a new thread at the last minutes of vote.
...
strict_mode is just controlling errors, then it should be named as
error
controlling directive and raise E_WARNING/E_TYPE or whatever.
Even if what its controlling is error that can be overridden by caller,
yet
calling it strict_types is not correct. Proper name would be something
like raise_type_error.
Let's see how it looks if strict_types is renamed to raise_type_error
...
?php
declare(raise_type_error = 1);
require lib.php;
foo(123); // will give an error
?
I agree that the name doesn't by itself explain the feature, but how
could it possibly? You'd end up with something like:
declare(raise_type_errors_on_parameter_mismatches_when_calling_functions_from_this_file_regardless_of_where_the_functions_are_defined_and_what_the_setting_is_in_other_files=1);
I don't think your suggestion explains the feature any better than
strict_types.
The word strict is not right word for the feature. It should not be used
to avoid
confusions at least.
Anyway, my point is Is everyone feel right about following behavior
regardless of
directive name.
?php
declare(raise_type_error = 1); // declare(strict_types=1) with the
RFC
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
?php
require lib.php;
foo(123); // will work
?
?php
declare(raise_type_error = 1); // declare(strict_types=1) with the
RFC
require lib.php;
foo(123); // will give an error
?
This is the same basically as
?php
error_reporting(E_TYPE);
function foo(int $a) {
// no function call here
}
?
The error_reporting() here does just nothing.
?php
require lib.php;
foo(123); // will work
?
?php
$old = error_reporting(E_TYPE);
require lib.php;
error_reporting($old);
foo(123); // will give an error
?
Does this make sense?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
