Point of clarification: it exists in the RFC already: https://wiki.php.net/rfc/scalar_type_hints_v5#internal_functions_should_opt-in_to_typing
On Fri, Feb 20, 2015 at 2:06 PM, Anthony Ferrara <ircmax...@gmail.com> wrote: > 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
