About declare(strict_types = 1)

9 years ago by Xinchen Hui — view source

unread

Hey:

 The most unaccept feature in current STH thing(v.5.0) is this.

 acutaly, I believe in most applications, they will still keep this off..

 so why we introduce such thing?

 beside this,  I have a question, which is not explained in the RFC:

 lib.php
 &lt;?php
   declare(strict_types = 1);
   function add(int $a, int $b) {
   }
 ?>

 assuming lib.php is a thrid part library which I want to use it

in my project.

 but I use whole weak types in my project..

 thus I simply call  add by:

 &lt;?php

  add($_GET['a'], $_GET['b']); //recoverable error  since all

input in _GET _POST is string by default

 ?>

 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.

 is that right?

thanks

--
Xinchen Hui
@Laruence
http://www.laruence.com/

9 years ago by Dennis Birkholz — view source

unread

Hello Xinchen,

Am 16.03.2015 um 06:28 schrieb Xinchen Hui:

 lib.php
 &lt;?php
   declare(strict_types = 1);
   function add(int $a, int $b) {
   }

 &lt;?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
?>

Very easy, explained a thousand times over. Bringing up the same false
arguments up again and again does really not help the discussion.

Greets
Dennis

9 years ago by Xinchen Hui — view source

unread

Hey:

Hello Xinchen,

Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
 lib.php
 &lt;?php
   declare(strict_types = 1);
   function add(int $a, int $b) {
   }

 &lt;?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
?>

Very easy, explained a thousand times over. Bringing up the same false
arguments up again and again does really not help the discussion.
That is why I don't see it before (thousand times, too long to read...
but not in RFC)

anyway, thanks for answering

then I have no further questions anymore.

thanks

Greets
Dennis

--

--
Xinchen Hui
@Laruence
http://www.laruence.com/

9 years ago by Matthew Leverton — view source

unread

That is why I don't see it before (thousand times, too long to read...
but not in RFC)

It's in the RFC: "Whether or not the function being called was
declared in a file that uses strict or weak type checking is
irrelevant. The type checking mode depends on the file where the
function is called."

If it were the other way around, then you'd be correct -- it would be
a disaster.

--
Matthew Leverton

9 years ago by Yasuo Ohgaki — view source

unread

Hi all,

On Mon, Mar 16, 2015 at 3:03 PM, Matthew Leverton leverton@gmail.com
wrote:

That is why I don't see it before (thousand times, too long to read...
but not in RFC)

It's in the RFC: "Whether or not the function being called was
declared in a file that uses strict or weak type checking is
irrelevant. The type checking mode depends on the file where the
function is called."

This is one of the point I most dislike.
Caller must satisfy callee requirements. This is simple principle to
write
a secure code.

With this RFC, caller overrides security related setting. This means
scripts
that are prepared for type safety is "ignored" and it leads security breach.

It's just like turning on/off register_globals and allow_url_include by
caller.
It cannot be right... IMHO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Dennis Birkholz — view source

unread

Hi Yasuo,

Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:

Caller must satisfy callee requirements. This is simple principle to
write a secure code.

With this RFC, caller overrides security related setting. This means
scripts
that are prepared for type safety is "ignored" and it leads security breach.

that is simply not true! The callee always gets the type it expects.
There is no security problem involved here. The only difference is if
type conversion rules apply or if an error is raised for a type mismatch.

You clearly dislike the RFC (you voted no), that is OK, but don't scream
of "security" bugs that don't exist. If they would exist, all type hint
RFCs would have them in general.

Greets,
Dennis

9 years ago by Yasuo Ohgaki — view source

unread

Hi Dennis,

On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz dennis@birkholz.biz
wrote:

Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:

Caller must satisfy callee requirements. This is simple principle to
write a secure code.

With this RFC, caller overrides security related setting. This means
scripts
that are prepared for type safety is "ignored" and it leads security
breach.

that is simply not true! The callee always gets the type it expects.
There is no security problem involved here. The only difference is if
type conversion rules apply or if an error is raised for a type mismatch.

You clearly dislike the RFC (you voted no), that is OK, but don't scream
of "security" bugs that don't exist. If they would exist, all type hint
RFCs would have them in general.

Not only Java/etc programmers but also PHP programmers will assume type
safety by types.

Programmers assume integer type data is safe once it passes as integer type
parameter.
I'm sure PHP programmer do assume the same thing.

I posted "bad code"

<?php
function check_num_range(int $num) { if ($num < 0 || $num > 100)
trigger_error('Invalid range'); }
// Somewhere far from function definition.
$num = $GET['num'];
// Somewhere far from $num definition.
check_num_range($num); // Trying to check validity, int and range.
echo 'You have '.$num. ' now <br />'; // But $num could have any string.
//
"check_num_range((int)$num)" wouldn't help also.
?>

Caller controlled strict typing makes this worse... i.e.
<?php
declare(strict_types=1);
// We are safe since $num is strictly int. Callee has responsibility to
pass valid int . (But it's not)
function check_num_range(int $num) { if ($num < 0 || $num > 100)
trigger_error('Invalid range'); }
?>

Setting register_globals=On while callee script assumes
register_globals=Off is bad thing to do.
Similar argument applies to declare(strict_types=1) also.

As I suggested in other thread, we are better to sit down and make
reasonable decision.
It's not religion, but technical issue. We can reach reasonable consensus
if we try to. If we
cannot, it is better to introduce weak type hint only for the time being.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Pierre Joye — view source

unread

Hi Dennis,

On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz dennis@birkholz.biz
wrote:

Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:

Caller must satisfy callee requirements. This is simple principle to
write a secure code.

With this RFC, caller overrides security related setting. This means
scripts
that are prepared for type safety is "ignored" and it leads security
breach.

that is simply not true! The callee always gets the type it expects.
There is no security problem involved here. The only difference is if
type conversion rules apply or if an error is raised for a type
mismatch.

You clearly dislike the RFC (you voted no), that is OK, but don't scream
of "security" bugs that don't exist. If they would exist, all type hint
RFCs would have them in general.

Not only Java/etc programmers but also PHP programmers will assume type
safety by types.

Programmers assume integer type data is safe once it passes as integer
type
parameter.
I'm sure PHP programmer do assume the same thing.

I posted "bad code"

<?php
function check_num_range(int $num) { if ($num < 0 || $num > 100)
trigger_error('Invalid range'); }
// Somewhere far from function definition.
$num = $GET['num'];
// Somewhere far from $num definition.
check_num_range($num); // Trying to check validity, int and range.
echo 'You have '.$num. ' now <br />'; // But $num could have any string.
//
"check_num_range((int)$num)" wouldn't help also.
?>

Caller controlled strict typing makes this worse... i.e.
<?php
declare(strict_types=1);
// We are safe since $num is strictly int. Callee has responsibility to
pass valid int . (But it's not)
function check_num_range(int $num) { if ($num < 0 || $num > 100)
trigger_error('Invalid range'); }
?>

Setting register_globals=On while callee script assumes
register_globals=Off is bad thing to do.
Similar argument applies to declare(strict_types=1) also.

As I suggested in other thread, we are better to sit down and make
reasonable decision.
It's not religion, but technical issue. We can reach reasonable consensus
if we try to. If we
cannot, it is better to introduce weak type hint only for the time being.

So basically you mixed topics and voted no for the one RFC that would allow
what you want to do later while allowing strict hinting already. Accepting
the other means changing casting rules again later at best. Not sure you
did well here ;-)

9 years ago by Yasuo Ohgaki — view source

unread

Hi Pierre,

Hi Dennis,

On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz dennis@birkholz.biz
wrote:

Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:

Caller must satisfy callee requirements. This is simple principle
to
write a secure code.

With this RFC, caller overrides security related setting. This means
scripts
that are prepared for type safety is "ignored" and it leads security
breach.

that is simply not true! The callee always gets the type it expects.
There is no security problem involved here. The only difference is if
type conversion rules apply or if an error is raised for a type
mismatch.

You clearly dislike the RFC (you voted no), that is OK, but don't
scream
of "security" bugs that don't exist. If they would exist, all type hint
RFCs would have them in general.

Not only Java/etc programmers but also PHP programmers will assume type
safety by types.

Programmers assume integer type data is safe once it passes as integer
type
parameter.
I'm sure PHP programmer do assume the same thing.

I posted "bad code"

<?php
function check_num_range(int $num) { if ($num < 0 || $num > 100)
trigger_error('Invalid range'); }
// Somewhere far from function definition.
$num = $GET['num'];
// Somewhere far from $num definition.
check_num_range($num); // Trying to check validity, int and range.
echo 'You have '.$num. ' now <br />'; // But $num could have any string.
//
"check_num_range((int)$num)" wouldn't help also.
?>

Caller controlled strict typing makes this worse... i.e.
<?php
declare(strict_types=1);
// We are safe since $num is strictly int. Callee has responsibility to
pass valid int . (But it's not)
function check_num_range(int $num) { if ($num < 0 || $num > 100)
trigger_error('Invalid range'); }
?>

Setting register_globals=On while callee script assumes
register_globals=Off is bad thing to do.
Similar argument applies to declare(strict_types=1) also.

As I suggested in other thread, we are better to sit down and make
reasonable decision.
It's not religion, but technical issue. We can reach reasonable consensus
if we try to. If we
cannot, it is better to introduce weak type hint only for the time being.

So basically you mixed topics and voted no for the one RFC that would
allow what you want to do later while allowing strict hinting already.
Accepting the other means changing casting rules again later at best. Not
sure you did well here ;-)

I thought majority of us see the benefit of StrictSTH over this RFC. You're
right about it.

This RFC will have serious consequence.
We made mistake with "safe_mode". The main reason it failed is "it did not
force
caller to have responsibility to make it work as it should". This RFC does
the same
for how declare(strict_types=1) works.

Aren't we learned from "safe_mode" lessons?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Derick Rethans — view source

unread

On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz dennis@birkholz.biz
wrote:

Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:

Caller must satisfy callee requirements. This is simple
principle to write a secure code.

With this RFC, caller overrides security related setting. This
means scripts that are prepared for type safety is "ignored"
and it leads security breach.

That's not true. The caller does not override any security setting. The
receiving function (callee) will always get the type they declared.
That is important for security.

When I first saw Andrea's v3, I was also of the opinion that it should
be the callee that controls whether the type hints should be strict or
not. But then I realized that it does not matter, as the callee will
get the right type regardless. Allowing the caller to decide whether it
throws an error or not, is irrelevant to any sort of security. Realizing
that it didn't matter, made me change my "no" vote to "yes".

I thought majority of us see the benefit of StrictSTH over this RFC.
You're right about it.

This RFC will have serious consequence. We made mistake with
"safe_mode". The main reason it failed is "it did not force caller to
have responsibility to make it work as it should". This RFC does the
same for how declare(strict_types=1) works.

Aren't we learned from "safe_mode" lessons?

I am not sure why you mention "safe_mode" as this has absolutely nothing
to do with scalar type hints. Not feature wise, not implementation wise.

safe_mode, first of all, was a global INI setting. The developer
couldn't turn it off easily. That was probably at least 80% of the pain.
The second part was the name, as it indicated that it made your scripts
safe: It didn't.

STHv5 does not suffer from either issue — developers can pick and choose
the best solution for them (give them some credit, most developers are
actually smart!). Library authors always get the right type if they type
hint, which is their main pain point. And the type names have always
already been used for casts anyway, and don't include "safe" in their
name.

cheers,
Derick

9 years ago by pajousek@gmail.com — view source

unread

This RFC will have serious consequence. We made mistake with
"safe_mode". The main reason it failed is "it did not force caller to
have responsibility to make it work as it should". This RFC does the
same for how declare(strict_types=1) works.

Aren't we learned from "safe_mode" lessons?

I am not sure why you mention "safe_mode" as this has absolutely nothing
to do with scalar type hints. Not feature wise, not implementation wise.

safe_mode, first of all, was a global INI setting. The developer
couldn't turn it off easily. That was probably at least 80% of the pain.
The second part was the name, as it indicated that it made your scripts
safe: It didn't.

STHv5 does not suffer from either issue — developers can pick and choose
the best solution for them (give them some credit, most developers are
actually smart!). Library authors always get the right type if they type
hint, which is their main pain point. And the type names have always
already been used for casts anyway, and don't include "safe" in their
name.

cheers,

Hello,

it's similiar to the safe_mode though. Sure, it's not as bad as INI
setting, but the "intent" is the same - a switch changing how code
behaves.

When I talked about the Dual Mode with some friends who are userland
PHP devs (either current or former, because they switched to other
stuff), none of them called the Dual Mode a great idea. The responses
I got were mostly along the lines of "wow, this seems really weird" to
"WTF are those developers smoking". Everyone of them (sure, ~10 people
isn't really representative number) said that they think PHP needs
STH, but not this Dual Mode stuff.

Seriously, think about it for a while - when some setting that changes
how code behaves was a good idea?

(IMHO never.)

Regards
Pavel Kouril

9 years ago by Dan Ackroyd — view source

unread

Seriously, think about it for a while - when some setting that changes
how code behaves was a good idea?

The problem is that there are two irreconcilable camps - some people
want weak STHs, other people want strict STHs.

This RFC gives both camps what they want, at the cost of having the dual mode.

I personally would prefer a single mode, with strict STHs but I can
see that would piss off the other camp. And so to me, this RFC even
with the ickiness of the setting, is an an acceptable cost to giving
both sides what they want. Oh, and people who don't want to use scalar
type hints at all, can still continue to not use scalar type hints,
and their code will continue to keep working.

Anyone who is voting no, isn't doing so because they are missing out
on a feature, they're doing it to block other people from getting what
they want in PHP, which is just a terrible way to vote.

And if the strict camp are wrong and strict scalars are just not used
by a large proportion of the PHP community, it would be trivial to
remove support for the strict mode in a future version of PHP, as all
code that runs in strict mode, will automatically work in weak mode.

cheers
Dan

9 years ago by pajousek@gmail.com — view source

unread

Seriously, think about it for a while - when some setting that changes
how code behaves was a good idea?

The problem is that there are two irreconcilable camps - some people
want weak STHs, other people want strict STHs.

This RFC gives both camps what they want, at the cost of having the dual mode.

I personally would prefer a single mode, with strict STHs but I can
see that would piss off the other camp. And so to me, this RFC even
with the ickiness of the setting, is an an acceptable cost to giving
both sides what they want. Oh, and people who don't want to use scalar
type hints at all, can still continue to not use scalar type hints,
and their code will continue to keep working.

Anyone who is voting no, isn't doing so because they are missing out
on a feature, they're doing it to block other people from getting what
they want in PHP, which is just a terrible way to vote.

And if the strict camp are wrong and strict scalars are just not used
by a large proportion of the PHP community, it would be trivial to
remove support for the strict mode in a future version of PHP, as all
code that runs in strict mode, will automatically work in weak mode.

cheers
Dan

I can't speak for anyone who voted, but personally, if I could vote, I
would voted "no" - not because "I don't want to block people from
getting what they want", but because I sincerely think that having ANY
setting that changes code's behavior is bad in the long run (and that
removing the feature might not be really easy, once people realize
that the feature is really bad, as people realized with safe_mode and
register_globals after few years).

I work on multiple projects for multiple clients - some have great
code base, some have a bad one. Different typing contexts in different
projects isn't going to help anything at all - it will only bring a
mental overhead.

It's really a shame the other way around wasn't put to vote - to add
weak types, and if there's still enough momentum for "strict"* types,
add them with the Dual Mode (although I would love to see PHP without
Dual Mode completly).

*) I also hate the name "strict" types, because this behavior is
called "strongly typed" in every other language I stumbled upon; why
does PHP have to be a special snowflake? But it's just an aesthetic
thing, so it doesn't matter THAT much.

PS: Also, I personally don't have a preference between strict or weak
typing. I wished from the first moment the Dual Mode was RFC'd that
just ONE ruleset would be chosen, and people would adapt to it. (Given
the weak nature of PHP, the weak types probably fit more, but I
personally could lived with either of those - just not at the same
time.)

Regards
Pavel Kouril

9 years ago by David Muir — view source

unread

Seriously, think about it for a while - when some setting that changes
how code behaves was a good idea?

The problem is that there are two irreconcilable camps - some people
want weak STHs, other people want strict STHs.

This RFC gives both camps what they want, at the cost of having the dual mode.

I personally would prefer a single mode, with strict STHs but I can
see that would piss off the other camp. And so to me, this RFC even
with the ickiness of the setting, is an an acceptable cost to giving
both sides what they want. Oh, and people who don't want to use scalar
type hints at all, can still continue to not use scalar type hints,
and their code will continue to keep working.

Anyone who is voting no, isn't doing so because they are missing out
on a feature, they're doing it to block other people from getting what
they want in PHP, which is just a terrible way to vote.

And if the strict camp are wrong and strict scalars are just not used
by a large proportion of the PHP community, it would be trivial to
remove support for the strict mode in a future version of PHP, as all
code that runs in strict mode, will automatically work in weak mode.

cheers
Dan

I can't speak for anyone who voted, but personally, if I could vote, I
would voted "no" - not because "I don't want to block people from
getting what they want", but because I sincerely think that having ANY
setting that changes code's behavior is bad in the long run (and that

Do you use an error handler that converts notices into exceptions? By your statement, I'm guessing no, and that you think error handlers should not be used that way as they change the code's behavior in almost exactly the same manner?

removing the feature might not be really easy, once people realize
that the feature is really bad, as people realized with safe_mode and
register_globals after few years).

Removing the feature is trivial! A search / replace across the code base can do it, and it could be disabled at the engine level. For working code, nobody would notice the difference because strict code works in weak mode. In other words, there are no BC issues with removing the strict portion.

Can people stop comparing it to register globals? Have you ever tried to fix a codebase that relied on it? It is impossible to detect! You really don't have many options but to step through and manually run through every single entry point into your application and test/audit every code path, and the hope you catch everything. It was a global setting, removing it was a huge BC break, and its use was undetectable. None of which is the case with dual mode. There's no global setting, there's no BC with removing it, and it's use is extremely easy to detect!

Cheers,
David

9 years ago by Pierre Joye — view source

unread

I can't speak for anyone who voted, but personally, if I could vote, I
would voted "no" - not because "I don't want to block people from
getting what they want", but because I sincerely think that having ANY
setting that changes code's behavior is bad in the long run (and that
removing the feature might not be really easy, once people realize
that the feature is really bad, as people realized with safe_mode and
register_globals after few years).

I work on multiple projects for multiple clients - some have great
code base, some have a bad one. Different typing contexts in different
projects isn't going to help anything at all - it will only bring a
mental overhead.

So you would have voted no on namespaces?

9 years ago by pajousek@gmail.com — view source

unread

I can't speak for anyone who voted, but personally, if I could vote, I
would voted "no" - not because "I don't want to block people from
getting what they want", but because I sincerely think that having ANY
setting that changes code's behavior is bad in the long run (and that
removing the feature might not be really easy, once people realize
that the feature is really bad, as people realized with safe_mode and
register_globals after few years).

I work on multiple projects for multiple clients - some have great
code base, some have a bad one. Different typing contexts in different
projects isn't going to help anything at all - it will only bring a
mental overhead.

So you would have voted no on namespaces?

You will probably have to try to explain the similiarity between a
setting that conceptually changes how language works and namespace. I
guess Derick wanted to do so, but his example doesn't make sense and I
didn't understand it, tbh.

Regards
Pavel Kouril

9 years ago by Jordi Boggiano — view source

unread

it's similiar to the safe_mode though. Sure, it's not as bad as INI
setting, but the "intent" is the same - a switch changing how code
behaves.

ini_set('memory_limit', 10); also changes how your code behave, but it's
global so that can be problematic.

die; changes how your code behave, but you can fix it if it doesn't do
what you want in your file.

Code has meaning and therefore code changes what the program does. I
don't think that's really a problem.

When I talked about the Dual Mode with some friends who are userland
PHP devs (either current or former, because they switched to other
stuff), none of them called the Dual Mode a great idea. The responses
I got were mostly along the lines of "wow, this seems really weird" to
"WTF are those developers smoking". Everyone of them (sure, ~10 people
isn't really representative number) said that they think PHP needs
STH, but not this Dual Mode stuff.

Seriously, think about it for a while - when some setting that changes
how code behaves was a good idea?

All your friends can happily ignore strict mode and no sysadmin can
enable it as it is per-file. Those of us that do understand it and might
want to use it can do so, and if your friends eventually go beyond the
"this seems really weird" phase (it is weird because it's an uncommon
approach to have both strict and non-strict in one language, but that
doesn't necessarily mean it's bad) maybe they'll want to use it too some
day. Or perhaps they'll need to start smoking.

Cheers,
Jordi

9 years ago by Derick Rethans — view source

unread

it's similiar to the safe_mode though. Sure, it's not as bad as INI
setting, but the "intent" is the same - a switch changing how code
behaves.

ini_set('memory_limit', 10); also changes how your code behave

And so does "namespace Foo; use Foo/DateTime as DateTime;" - on exactly
the same level as "declare"...

cheers,
Derick

9 years ago by pajousek@gmail.com — view source

unread

it's similiar to the safe_mode though. Sure, it's not as bad as INI
setting, but the "intent" is the same - a switch changing how code
behaves.

ini_set('memory_limit', 10); also changes how your code behave

And so does "namespace Foo; use Foo/DateTime as DateTime;" - on exactly
the same level as "declare"...

cheers,
Derick

Hello,

sorry, but your comparison doesn't make ANY sense whatsoever.

Regards
Pavel Kouril

9 years ago by Pierre Joye — view source

unread

it's similiar to the safe_mode though. Sure, it's not as bad as INI
setting, but the "intent" is the same - a switch changing how code
behaves.

ini_set('memory_limit', 10); also changes how your code behave, but it's
global so that can be problematic.

die; changes how your code behave, but you can fix it if it doesn't do
what you want in your file.

Code has meaning and therefore code changes what the program does. I
don't think that's really a problem.

When I talked about the Dual Mode with some friends who are userland
PHP devs (either current or former, because they switched to other
stuff), none of them called the Dual Mode a great idea. The responses
I got were mostly along the lines of "wow, this seems really weird" to
"WTF are those developers smoking". Everyone of them (sure, ~10 people
isn't really representative number) said that they think PHP needs
STH, but not this Dual Mode stuff.

Seriously, think about it for a while - when some setting that changes
how code behaves was a good idea?

All your friends can happily ignore strict mode and no sysadmin can
enable it as it is per-file. Those of us that do understand it and might
want to use it can do so, and if your friends eventually go beyond the
"this seems really weird" phase (it is weird because it's an uncommon
approach to have both strict and non-strict in one language, but that
doesn't necessarily mean it's bad) maybe they'll want to use it too some
day. Or perhaps they'll need to start smoking.

Btw, I have seen similar comment (to the ones in this thread) about the
windows-like separator for namespaces. Guess what? Nobody cares now. :)

9 years ago by Derick Rethans — view source

unread

This RFC will have serious consequence. We made mistake with
"safe_mode". The main reason it failed is "it did not force caller
to have responsibility to make it work as it should". This RFC does
the same for how declare(strict_types=1) works.

Aren't we learned from "safe_mode" lessons?

I am not sure why you mention "safe_mode" as this has absolutely
nothing to do with scalar type hints. Not feature wise, not
implementation wise.

safe_mode, first of all, was a global INI setting. The developer
couldn't turn it off easily. That was probably at least 80% of the
pain. The second part was the name, as it indicated that it made
your scripts safe: It didn't.

STHv5 does not suffer from either issue — developers can pick and
choose the best solution for them (give them some credit, most
developers are actually smart!). Library authors always get the
right type if they type hint, which is their main pain point. And
the type names have always already been used for casts anyway, and
don't include "safe" in their name.

it's similiar to the safe_mode though. Sure, it's not as bad as INI
setting, but the "intent" is the same - a switch changing how code
behaves.

The intent is no where near the same.

safe_mode is an evil monster from the depts of a lone sysadm that sees
"oh it's safe" - without a developer having a chance to do anything
about it.

strict is an option mode that a developer that writes a specific PHP
file can opt into.

Absolutely not even the same magnitude of evil.

cheers,
Derick

9 years ago by Anton Osrdek — view source

unread

Hello,

it's similiar to the safe_mode though. Sure, it's not as bad as INI
setting, but the "intent" is the same - a switch changing how code
behaves.

When I talked about the Dual Mode with some friends who are userland
PHP devs (either current or former, because they switched to other
stuff), none of them called the Dual Mode a great idea. The responses
I got were mostly along the lines of "wow, this seems really weird" to
"WTF are those developers smoking". Everyone of them (sure, ~10 people
isn't really representative number) said that they think PHP needs
STH, but not this Dual Mode stuff.

Seriously, think about it for a while - when some setting that changes
how code behaves was a good idea?

(IMHO never.)

Regards
Pavel Kouril

--

I was like that in the beginning when Andrea introduced the declare syntax.
But this was because of a fundamental misunderstanding how declare actually
works.
Now I think it's a brilliant solution to introduce optional strict type
hinting. It does not force a user who uses week type hinting to use, care
or even know about strict type hinting.

9 years ago by Xinchen Hui — view source

unread

Hey:

That is why I don't see it before (thousand times, too long to read...
but not in RFC)

It's in the RFC: "Whether or not the function being called was
declared in a file that uses strict or weak type checking is
irrelevant. The type checking mode depends on the file where the
function is called."
my fault, I must oversight of reading this...

thanks

If it were the other way around, then you'd be correct -- it would be
a disaster.

--
Matthew Leverton

--
Xinchen Hui
@Laruence
http://www.laruence.com/

9 years ago by Lester Caine — view source

unread

It's in the RFC: "Whether or not the function being called was

declared in a file that uses strict or weak type checking is
irrelevant. The type checking mode depends on the file where the
function is called."
my fault, I must oversight of reading this...

If the third party library has been 'converted' to strict, and is
expecting strict typing to pick up the sort of conversions that the
strict camp want to protect against then there are handlers for that
error, but if it is called from a situation where weak conversions are
all that is being passed would it be necessary to add back in weak error
handling as well if the library is not actually designed to handle those
cases?

I know all of this has been said a thousand times, but we do not
CURRENTLY have type hinting, if projects are going to start relying on
weak hinting or strict hinting, then is there any guarantee that there
will not be new edge cases when mixing the two methods of working. Add
in the fact that we do not HAVE to use it so the calling project may
simply not be bothering about hinting at all? But now has to handle new
errors which start when a library adds any hinting?

--
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

9 years ago by Yasuo Ohgaki — view source

unread

Hi all,

On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz dennis@birkholz.biz
wrote:

Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
 lib.php
 &lt;?php
   declare(strict_types = 1);
   function add(int $a, int $b) {
   }

 &lt;?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 strict? It's not
strict at all if mode could be overridden.

"strict_mode" is just controlling errors, then it should be handled as
error E_WARNING/E_TYPE or whatever.

Even if what it controlling is error that can be overridden by caller, yet
calling it "strict" is not correct. Proper name would be something
like "raise_type_error".

Let 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??

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Mike Willbanks — view source

unread

Hi all,

On Mon, Mar 16, 2015 at 2:49 PM, Dennis Birkholz dennis@birkholz.biz
wrote:
Am 16.03.2015 um 06:28 schrieb Xinchen Hui:
 lib.php
 &lt;?php
   declare(strict_types = 1);
   function add(int $a, int $b) {
   }

 &lt;?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 strict? It's not
strict at all if mode could be overridden.

"strict_mode" is just controlling errors, then it should be handled as
error E_WARNING/E_TYPE or whatever.

Even if what it controlling is error that can be overridden by caller, yet
calling it "strict" is not correct. Proper name would be something
like "raise_type_error".

Let 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??

That seems far more odd in my opinion. I vastly prefer the first.

9 years ago by Yasuo Ohgaki — view source

unread

Hi Mike,

Let 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??

That seems far more odd in my opinion. I vastly prefer the first.

The name implies what it does.
The reason you think this is odd is because the behavior is odd.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Pierre Joye — view source

unread

Hi,

Hey:

 The most unaccept feature in current STH thing(v.5.0) is this.

 acutaly, I believe in most applications, they will still keep this

off..

 so why we introduce such thing?

 beside this,  I have a question, which is not explained in the RFC:

 lib.php
 &lt;?php
   declare(strict_types = 1);
   function add(int $a, int $b) {
   }
 ?>

 assuming lib.php is a thrid part library which I want to use it

in my project.

 but I use whole weak types in my project..

 thus I simply call  add by:

 &lt;?php

  add($_GET['a'], $_GET['b']); //recoverable error  since all

input in _GET _POST is string by default

 ?>

 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.

 is that right?

You got the answer but one thing bothers me a lot right now.

How did you vote against this rfc while missing the core point of it (after
actually having a strict mode)?

9 years ago by Xinchen Hui — view source

unread

Hey:

Hi,
Hey:
 The most unaccept feature in current STH thing(v.5.0) is this.

 acutaly, I believe in most applications, they will still keep this
off..
 so why we introduce such thing?

 beside this,  I have a question, which is not explained in the RFC:

 lib.php
 &lt;?php
   declare(strict_types = 1);
   function add(int $a, int $b) {
   }
 ?>

 assuming lib.php is a thrid part library which I want to use it
in my project.
 but I use whole weak types in my project..

 thus I simply call  add by:

 &lt;?php

  add($_GET['a'], $_GET['b']); //recoverable error  since all
input in _GET _POST is string by default
 ?>

 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.
 is that right?
You got the answer but one thing bothers me a lot right now.

How did you vote against this rfc while missing the core point of it (after
actually having a strict mode)?
as I said,
"
acutaly, I believe in most applications, they will still keep this off..

so why we introduce such thing?
"
I don't like strict_types at all..

the question I asked is just want one of my concern is not ture, or
not oversight by others.

thanks

--
Xinchen Hui
@Laruence
http://www.laruence.com/

9 years ago by Dan Ackroyd — view source

unread

Hey:
I don't like strict_types at all..

And you would never be forced to use them.

But you're voting against allowing anyone else to use them. :-(

cheers
Dan

9 years ago by Derick Rethans — view source

unread

 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.
 is that right?
You got the answer but one thing bothers me a lot right now.

How did you vote against this rfc while missing the core point of it (after
actually having a strict mode)?

as I said,
"
acutaly, I believe in most applications, they will still keep this off..

so why we introduce such thing?
"
I don't like strict_types at all..

To be frank, I don't think "I don't like this" is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the "declare" syntax, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
best bet, I can only vote "yes".

cheers,
Derick

9 years ago by Xinchen Hui — view source

unread

Hey:

 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.
 is that right?
You got the answer but one thing bothers me a lot right now.

How did you vote against this rfc while missing the core point of it (after
actually having a strict mode)?
as I said,
"
acutaly, I believe in most applications, they will still keep this off..

so why we introduce such thing?
"
I don't like strict_types at all..

To be frank, I don't think "I don't like this" is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the "declare" syntax, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
I think they just want a weak type hintings(PHP is a weak type
language).. not strict types.

especially not a dual mode, switch on/off by a declare line..

it looks so ugly to me..

strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
best bet, I can only vote "yes".
I understand your choice, but for me, as a six year PHP user. I can
see how strict types can benifit me..

the only usage I can image is, turn on it in developer env to clean
types passing, and turn off in produce env for safety(in case I forget
to cast some types from $_GET $_POST).

which is definitlely can be done by a extension, or hook..

thanks

cheers,
Derick

--
Xinchen Hui
@Laruence
http://www.laruence.com/

9 years ago by Xinchen Hui — view source

unread

Hey:
 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.
 is that right?
You got the answer but one thing bothers me a lot right now.

How did you vote against this rfc while missing the core point of it (after
actually having a strict mode)?
as I said,
"
acutaly, I believe in most applications, they will still keep this off..

so why we introduce such thing?
"
I don't like strict_types at all..

To be frank, I don't think "I don't like this" is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the "declare" syntax, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
I think they just want a weak type hintings(PHP is a weak type
language).. not strict types.
especially not a dual mode, switch on/off by a declare line..

it looks so ugly to me..

strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
best bet, I can only vote "yes".
I understand your choice, but for me, as a six year PHP user. I can
see how strict types can benifit me..
can not

the only usage I can image is, turn on it in developer env to clean
types passing, and turn off in produce env for safety(in case I forget
to cast some types from $_GET $_POST).

which is definitlely can be done by a extension, or hook..

thanks

cheers,
Derick

--
Xinchen Hui
@Laruence
http://www.laruence.com/

--
Xinchen Hui
@Laruence
http://www.laruence.com/

9 years ago by Yasuo Ohgaki — view source

unread

Hi Derick,

On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye pierre.php@gmail.com
wrote:
 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.
 is that right?
You got the answer but one thing bothers me a lot right now.

How did you vote against this rfc while missing the core point of it
(after
actually having a strict mode)?
as I said,
"
acutaly, I believe in most applications, they will still keep this off..

so why we introduce such thing?
"
I don't like strict_types at all..

To be frank, I don't think "I don't like this" is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the "declare" syntax, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
best bet, I can only vote "yes".

Are you sure on your bet?

lib.php:
<?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?>
The declare here does just nothing.

a.php:
<?php
require "lib.php";
foo("123"); // will work
?>

b.php:
<?php
declare(strict_types = 1);
require "lib.php";
foo("123"); // will give an error
?>

This behavior is unacceptable.
Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
work as it should. Otherwise, all kinds of unexpected for lib.php and it's
users may happen.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Xinchen Hui — view source

unread

Hey:

Hi Derick,
On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye pierre.php@gmail.com
wrote:
 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.
 is that right?
You got the answer but one thing bothers me a lot right now.

How did you vote against this rfc while missing the core point of it
(after
actually having a strict mode)?
as I said,
"
acutaly, I believe in most applications, they will still keep this
off..

so why we introduce such thing?
"
I don't like strict_types at all..

To be frank, I don't think "I don't like this" is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the "declare" syntax, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
best bet, I can only vote "yes".
Are you sure on your bet?

lib.php:
<?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?>
The declare here does just nothing.

a.php:
<?php
require "lib.php";
foo("123"); // will work
?>

b.php:
<?php
declare(strict_types = 1);
require "lib.php";
foo("123"); // will give an error
?>

This behavior is unacceptable.
Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
work as it should. Otherwise, all kinds of unexpected for lib.php and it's
users may happen.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

And last comment, if there no such declare thing, I will definitely
vote yes to this RFC.

that's why I want vote no for this, and wait for Bob's Basic STH.

thanks

--
Xinchen Hui
@Laruence
http://www.laruence.com/

9 years ago by Derick Rethans — view source

unread

And last comment, if there no such declare thing, I will definitely
vote yes to this RFC.

that's why I want vote no for this, and wait for Bob's Basic STH.

That will not be in PHP 7.0 though, as the deadline passed.

And I can probably bet on that Basic STH not passing either. So you'll
end up with nothing. Thanks!

cheers,
Derick

9 years ago by Pascal Chevrel — view source

unread

Le 16/03/2015 12:39, Xinchen Hui a écrit :

Hey:

And last comment, if there no such declare thing, I will definitely
vote yes to this RFC.

Hi Xinchen,

You can also not vote at all, that's a very valid option.
By voting yes, you say that you want PHP developers to have access to
STH in PHP 7, by voting No, you say that you don't want PHP developers
to be able to use STH in PHP 7. By not voting, you let the rest of the
PHP community that cares about STH (both for and against) decide if the
feature gets in the language. As a person with voting rights, you should
study the RFCs in details, understand them fully and vote on what you
think you have understanding and expertise on. There is no obligation to
vote on all RFCs.

It seems that you won't use STH yourself so you will probably never use
declare in your code and won't be impacted by the existence or not of
the feature. I also don't like how the declare syntax looks, and
similarily I personnally dislike even more how ugly the namespace syntax
is in PHP with the backslashes (Foo\Bar\Baz), yet, I am happy that we do
have the possibility to namespace our code, because PHP 5 needed that
feature. And I think PHP 7 needs something like that, I also think it's
a very clever solution as we can keep on using PHP as a weakly typed
language as usual but also strenghten some of our code that needs strong
typing.

that's why I want vote no for this, and wait for Bob's Basic STH.

thanks

It's too late, Bob's Basic STH missed the schedule for PHP 7, it was
proposed way too late and the coercive STH RFC has just zero chance to
pass, it's too much of a BC break for everybody. The dual mode STH is
the only chance to have something for PHP 7 and remain competitive with
HHVM, Node.js… that we see people switch to. Baidu switched to HHVM,
Wikipedia too, in my country big names switched from PHP to node.js and
that was not just for performance reasons, it was also for the features.
Zeev himself admitted that we need something for PHP 7.

Personnally, I think the dual mode is a very clever way to please all
PHP developpers, those that want to use weak typing, those that want to
use stronger typing and those like me that would continue to use weak
typing because it's convenient but would be happy to use STH on very
specific parts of his code that would benefit from it.

Cheers,

Pascal

9 years ago by Xinchen Hui — view source

unread

Hey:

Le 16/03/2015 12:39, Xinchen Hui a écrit :

Hey:

And last comment, if there no such declare thing, I will definitely
vote yes to this RFC.

Hi Xinchen,

You can also not vote at all, that's a very valid option.
By voting yes, you say that you want PHP developers to have access to STH in
PHP 7, by voting No, you say that you don't want PHP developers to be able
to use STH in PHP 7. By not voting, you let the rest of the PHP community
that cares about STH (both for and against) decide if the feature gets in
the language. As a person with voting rights, you should study the RFCs in
details, understand them fully and vote on what you think you have
understanding and expertise on. There is no obligation to vote on all RFCs.

It seems that you won't use STH yourself so you will probably never use
declare in your code and won't be impacted by the existence or not of the
feature. I also don't like how the declare syntax looks, and similarily I
personnally dislike even more how ugly the namespace syntax is in PHP with
the backslashes (Foo\Bar\Baz), yet, I am happy that we do have the
possibility to namespace our code, because PHP 5 needed that feature. And
I think PHP 7 needs something like that, I also think it's a very clever
solution as we can keep on using PHP as a weakly typed language as usual but
also strenghten some of our code that needs strong typing.

that's why I want vote no for this, and wait for Bob's Basic STH.

thanks

It's too late, Bob's Basic STH missed the schedule for PHP 7, it was
proposed way too late and the coercive STH RFC has just zero chance to pass,
it's too much of a BC break for everybody. The dual mode STH is the only
chance to have something for PHP 7 and remain competitive with HHVM,
Node.js… that we see people switch to. Baidu switched to HHVM, Wikipedia
too, in my country big names switched from PHP to node.js and that was not
just for performance reasons, it was also for the features. Zeev himself
admitted that we need something for PHP 7.

Personnally, I think the dual mode is a very clever way to please all PHP
developpers, those that want to use weak typing, those that want to use
stronger typing and those like me that would continue to use weak typing
because it's convenient but would be happy to use STH on very specific parts
of his code that would benefit from it.
don't worry, it will pass

thanks

Cheers,

Pascal

--

--
Xinchen Hui
@Laruence
http://www.laruence.com/

9 years ago by Peter Petermann — view source

unread

It's too late, Bob's Basic STH missed the schedule for PHP 7, it was
proposed way too late and the coercive STH RFC has just zero chance to
pass, it's too much of a BC break for everybody. The dual mode STH is
the only chance to have something for PHP 7 and remain competitive with
Rushing through with an controversial solution, because others didn't make a date seems like such a good plan.

No one is dying if STH doesn't make it into 7.0.0.

HHVM, Node.js… that we see people switch to. Baidu switched to HHVM,
Wikipedia too, in my country big names switched from PHP to node.js and
that was not just for performance reasons, it was also for the
features.
hhvm offers an alternative php implementation that tries to be compatible, hack(lang) is where you find the differences you are looking for. That said, I don't see the sky falling if people who need a specific feature use another tool. The adoption rate of hack is tiny.

As for nodejs, nodejs is a framework, not a language. Javascript does not offer type hints. And if you look at how to compete with nodejs, then what you should be looking at is what needs to be improved with php to allow frameworks like reactphp to work better. How to improve support for non-blocking io.

And I dunno, but I don't think that "per file" settings make the callback-heavy code that's typical for non-blocking stuff better, in fact I'm convinced it will add an additional layer of headache.

Zeev himself admitted that we need something for PHP 7.
If it is THAT important for PHP 7 (and IMHO it's not) then maybe the timeline for PHP 7 needs to be reevaluated, to make sure all dependencies are the best option and not something rushed in because of ::conflict::.

Personnally, I think the dual mode is a very clever way to please all
PHP developpers, those that want to use weak typing, those that want to
use stronger typing and those like me that would continue to use weak
typing because it's convenient but would be happy to use STH on very
specific parts of his code that would benefit from it.
Personally I think STH is a nice to have, and not worth the confusion that per-file declares create.

I'd rather see no STH, or either one of the two ways than dual mode.

regards,
PP

9 years ago by Pierre Joye — view source

unread

On March 16, 2015 2:32:39 PM GMT+01:00, Pascal Chevrel <
pascal.chevrel@free.fr> wrote:

It's too late, Bob's Basic STH missed the schedule for PHP 7, it was
proposed way too late and the coercive STH RFC has just zero chance to
pass, it's too much of a BC break for everybody. The dual mode STH is
the only chance to have something for PHP 7 and remain competitive with
Rushing through with an controversial solution, because others didn't
make a date seems like such a good plan.

No one is dying if STH doesn't make it into 7.0.0.

No one will die if php dies. Your point here is totally irrelevant.

HHVM, Node.js… that we see people switch to. Baidu switched to HHVM,
Wikipedia too, in my country big names switched from PHP to node.js and
that was not just for performance reasons, it was also for the
features.
hhvm offers an alternative php implementation that tries to be
compatible, hack(lang) is where you find the differences you are looking
for. That said, I don't see the sky falling if people who need a specific
feature use another tool. The adoption rate of hack is tiny.

As for nodejs, nodejs is a framework, not a language. Javascript does not
offer type hints. And if you look at how to compete with nodejs, then what
you should be looking at is what needs to be improved with php to allow
frameworks like reactphp to work better. How to improve support for
non-blocking io.

And I dunno, but I don't think that "per file" settings make the
callback-heavy code that's typical for non-blocking stuff better, in fact
I'm convinced it will add an additional layer of headache.

Zeev himself admitted that we need something for PHP 7.
If it is THAT important for PHP 7 (and IMHO it's not) then maybe the
timeline for PHP 7 needs to be reevaluated, to make sure all dependencies
are the best option and not something rushed in because of ::conflict::.

I think you may talk to more developers. I have talked to many, at many
confs and UGs (and way too many in the last few weeks, across the pacific),
I can count users not looking for STH with one hand.

9 years ago by Peter Petermann — view source

unread

On Mar 17, 2015 7:05 AM, "Peter Petermann" ppetermann80@gmail.com
wrote:

On March 16, 2015 2:32:39 PM GMT+01:00, Pascal Chevrel <
pascal.chevrel@free.fr> wrote:

It's too late, Bob's Basic STH missed the schedule for PHP 7, it was
proposed way too late and the coercive STH RFC has just zero chance
to
pass, it's too much of a BC break for everybody. The dual mode STH
is
the only chance to have something for PHP 7 and remain competitive
with
Rushing through with an controversial solution, because others didn't
make a date seems like such a good plan.

No one is dying if STH doesn't make it into 7.0.0.

No one will die if php dies. Your point here is totally irrelevant.
PHP isn't dying without it. At least it hasn't in the last few years since it exists.

HHVM, Node.js… that we see people switch to. Baidu switched to HHVM,
Wikipedia too, in my country big names switched from PHP to node.js
and
that was not just for performance reasons, it was also for the
features.
hhvm offers an alternative php implementation that tries to be
compatible, hack(lang) is where you find the differences you are
looking
for. That said, I don't see the sky falling if people who need a
specific
feature use another tool. The adoption rate of hack is tiny.

As for nodejs, nodejs is a framework, not a language. Javascript does
not
offer type hints. And if you look at how to compete with nodejs, then
what
you should be looking at is what needs to be improved with php to allow
frameworks like reactphp to work better. How to improve support for
non-blocking io.

And I dunno, but I don't think that "per file" settings make the
callback-heavy code that's typical for non-blocking stuff better, in
fact
I'm convinced it will add an additional layer of headache.

Zeev himself admitted that we need something for PHP 7.
If it is THAT important for PHP 7 (and IMHO it's not) then maybe the
timeline for PHP 7 needs to be reevaluated, to make sure all
dependencies
are the best option and not something rushed in because of
::conflict::.

I think you may talk to more developers. I have talked to many, at many
confs and UGs (and way too many in the last few weeks, across the
pacific),
I can count users not looking for STH with one hand.
As I said, if you take it for THAT important, it should be in your own interest to get it right instead of rushing through a controversial compromise.

Regards,
PP.

9 years ago by Nikita Nefedov — view source

unread

On Mon, 16 Mar 2015 14:33:00 +0300, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:

Hi Derick,

To be frank, I don't think "I don't like this" is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the "declare" syntax, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
best bet, I can only vote "yes".

Are you sure on your bet?

lib.php:
<?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?>
The declare here does just nothing.

a.php:
<?php
require "lib.php";
foo("123"); // will work
?>

b.php:
<?php
declare(strict_types = 1);
require "lib.php";
foo("123"); // will give an error
?>

This behavior is unacceptable.
Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
work as it should. Otherwise, all kinds of unexpected for lib.php and
it's
users may happen.

When called from a.php, foo() will get and int(123), this is exactly what
is expected. Author of a.php acknowledges that all arguments in fcalls
from this file will be converted to appropriate types, this is basically
how all our internal functions work currently and it's perfectly
acceptable. But if you don't want this kind of type juggling then you
opt-in strict types. This is basically as easy as it gets, I don't see any
way to make it simpler. There's nothing to evolve in this RFC, it covers
pretty much everything and the idea of allowing for caller to make a
decision is, in my opinion, a great win in this situation.

9 years ago by Yasuo Ohgaki — view source

unread

On Mon, 16 Mar 2015 14:33:00 +0300, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:

Hi Derick,

To be frank, I don't think "I don't like this" is a terribly good reason

to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the "declare" syntax, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
best bet, I can only vote "yes".

Are you sure on your bet?

lib.php:
<?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?>
The declare here does just nothing.

a.php:
<?php
require "lib.php";
foo("123"); // will work
?>

b.php:
<?php
declare(strict_types = 1);
require "lib.php";
foo("123"); // will give an error
?>

This behavior is unacceptable.
Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
work as it should. Otherwise, all kinds of unexpected for lib.php and it's
users may happen.

When called from a.php, foo() will get and int(123), this is exactly what
is expected. Author of a.php acknowledges that all arguments in fcalls from
this file will be converted to appropriate types, this is basically how all
our internal functions work currently and it's perfectly acceptable. But if
you don't want this kind of type juggling then you opt-in strict types.
This is basically as easy as it gets, I don't see any way to make it
simpler. There's nothing to evolve in this RFC, it covers pretty much
everything and the idea of allowing for caller to make a decision is, in my
opinion, a great win in this situation.

I already showed real world example how this could be fail.

If we need this kind of behavior. I would suggest to have type affinity
like SQLite for
$_GET/$_POST/$_COOKIE.

https://www.sqlite.org/datatype3.html

This would work better to work with strict types.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

9 years ago by Nikita Nefedov — view source

unread

On Mon, 16 Mar 2015 14:50:16 +0300, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:

I already showed real world example how this could be fail.

If we need this kind of behavior. I would suggest to have type affinity
like SQLite for
$_GET/$_POST/$_COOKIE.

https://www.sqlite.org/datatype3.html

This would work better to work with strict types.

I don't see how, given your example, anything would fail. Do you imply
that function would get coerced value, but outside of the function
you would still have a string and the problem that this string could
contain anything?

If that's what you were trying to say then I don't consider this as a
problem, it's natural flow. If you were to implement type verification
in your function on your own you'd get the same results.

Perhaps you meant something different?

9 years ago by Lee Davis — view source

unread

Hi Derick,
On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye pierre.php@gmail.com
wrote:
 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.
 is that right?
You got the answer but one thing bothers me a lot right now.

How did you vote against this rfc while missing the core point of it
(after
actually having a strict mode)?
as I said,
"
acutaly, I believe in most applications, they will still keep this
off..

so why we introduce such thing?
"
I don't like strict_types at all..

To be frank, I don't think "I don't like this" is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the "declare" syntax, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
best bet, I can only vote "yes".
Are you sure on your bet?

lib.php:
<?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?>
The declare here does just nothing.

a.php:
<?php
require "lib.php";
foo("123"); // will work
?>

b.php:
<?php
declare(strict_types = 1);
require "lib.php";
foo("123"); // will give an error
?>

This behavior is unacceptable.
Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
work as it should. Otherwise, all kinds of unexpected for lib.php and it's
users may happen.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Hi Yasuo,

The expectation here has been made by the caller (i.e. they’ve put
declare strict=1 in their file). It’s not an expectation of the library.
The library get’s the types it wants (whether they're coerced or not)
regardless of what the caller does, and the caller get’s the benefit of
being able to assure all their parameter types are correct.

/@leedavis81

9 years ago by Derick Rethans — view source

unread

 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.
 is that right?
You got the answer but one thing bothers me a lot right now.

How did you vote against this rfc while missing the core point
of it (after actually having a strict mode)?
as I said,
"
acutaly, I believe in most applications, they will still keep this off..
so why we introduce such thing?
"
I don't like strict_types at all..

To be frank, I don't think "I don't like this" is a terribly good reason
to vote against (or for something). What is important is how many people
would actually benefit from a feature, without it causing issues for
others. I am certainly no fan of the "declare" syntax, but I do know,
from talking at conferences that many many developers would like to see
scalar type hints in some way — both weak (mode 1 of the STHv5 RFC), and
strict (mode 2). It even caters for people that don't want to use them
at all, as they can simply not use them. I also know, that without a
dual mode, it seems very unlikely for scalar type hints to make it
into PHP 7, and I don't think that is what users want. As this is our
best bet, I can only vote "yes".
Are you sure on your bet?

The "bet" refered to having type hints at all, ever.

lib.php:
<?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?>
The declare here does just nothing.

a.php:
<?php
require "lib.php";
foo("123"); // will work
?>

b.php:
<?php
declare(strict_types = 1);
require "lib.php";
foo("123"); // will give an error
?>

This behavior is unacceptable.

Why? The foo() function's $a variable is going to be an int, or the
function isn't called due to "strict" mode. There is no safety concern
for the value of $a.

Caller (a.php, b.php) must satisfy lib.php expectation to make lib.php
work as it should.

And it does - the result in foo() is the same.

Otherwise, all kinds of unexpected for lib.php and it's users may
happen.

You're mistaken. There is NO difference in the body of the foo()
function whether you have strict_types on (second example), or off
(first example).

cheers,
Derick

About declare(strict_types = 1)

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL