Rasmus, > To be perfectly transparent here though, you should mention that your > proposed RFC goes well beyond the strict typing that is in Hack because > in Hack the internal API is largely untyped while your proposal is to > default the entire internal API to strict types in strict mode. Also, in > Hack there is a distinction between the off-line hh_client type-checker > and the runtime.
In addition to what Josh said, I want to make one point here. This distinction is what lead me to push out 0.5 instead of where 0.4 was going. Let me explain: Let's say we don't type internal functions and release 7.1 with the rest of the dual mode type system. Then we're bound to never strictly type internal functions *unless* we introduce a NEW declare setting (declare(strict_types=2) or declare(internal_strict_types=1) or whatever). Which is a bit out there considering people already are testy about this one. So that practically means if we don't allow strict now, we can never tighten it again. However, if we do allow typed now, then we can expand and loosen in the future. If an API is found to be overly strict, it can be loosened (using a union type for example). We have the ability to loosen over time, but not strengthen. That's why I chose to apply the same typing to internal functions as user-land. To not to would be a major mistake IMHO. So that's why I'm moving forward with it. I will add this to discussion points in the RFC. > So when you say, and as I have heard other people say, that people want > Hack-like strict typing, you have to be a bit careful about what is > meant by that. Even in the cases where the internal API is typed in > Hack, it is still not a runtime fatal if they are called with the wrong > types. Now whether that is a good thing or not is debatable, of course, > my point is simply that if you are going to use Hack adoption as a sign > "that people want static typing" you should clearly explain that your > approach is quite different from what Hack is doing. It's not "quite different". It's subtly different in a few details. But conceptually it's the same. > Right, you are doing a gradual transition of an API that wasn't written > to be strict. It was written with the assumption that type coercion > would take place. If there is a good reason to ease the transition from > PHP to Hack there is an even stronger reason to ease the transition from > PHP to PHP. And that's why the current proposal has two modes: weak (coercive) and strict (error inducing). The default mode will not change things for anyone. Then they can start adding types, and things will just work. When they are ready, then they can turn on strict mode, one file at a time. Heck, they can run a strict-mode static analyzer on non-strict code to see where potential problems will be (assuming the analyzer has that mode) so they can fix it before committing to strict types in their production app. If that's not the definition of a "gradual transition", I'm not sure what else can be done without fundamentally disallowing the ability to strictly type. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
