On Mon, 16 Mar 2015, Pavel Kouřil wrote: > >> 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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
