On Mon, 16 Mar 2015, Yasuo Ohgaki wrote: > On Mon, Mar 16, 2015 at 5:17 PM, Pierre Joye <pierre....@gmail.com> wrote: > > > On Mar 16, 2015 6:46 PM, "Yasuo Ohgaki" <yohg...@ohgaki.net> wrote: > > > > > > On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz <den...@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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php