>> >> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
