On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds <a...@ajf.me> wrote: > Good evening, > > At long last, I’m going to put the RFC to a vote. It’s been long enough - > I don’t think there needs to be, or will be, much further discussion. > > I’d like to make sure that everyone voting understands the RFC fully. > Please read the RFC in full: the details are important. And if anyone has > any questions or uncertainties, please ask them before voting. I am very > happy to answer them. > > I would urge everyone who wants type hints to vote for this RFC. It is not > a perfect solution, but there can be no perfect solution to this issue. > However, I think it is better than most of the alternatives suggested thus > far - see the rationale section, and previous discussions. Crucially, this > RFC would keep PHP a weakly-typed language, and not force either strict > typing, nor weak typing, on anyone who does not want it. It would allow the > addition of type hints to existing codebases. It would not create a > situation where userland functions are strict yet internal functions are > not, because the strict mode affects both. I’ve tested the implementation > myself on my own code, and it worked well, providing benefits other > proposals would not have given (see my previous post about my experiences). > > Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). > In addition to the vote on the main RFC, there is also a vote on the type > aliases issue, and a vote to reserve the type names for future RFCs’ sake > if this RFC fails. > > The RFC can be found here, and it contains a voting widget: > https://wiki.php.net/rfc/scalar_type_hints > > Thank you for your time. >
After much initial reluctance, I've voted in favor of this RFC. I'm a proponent of strict scalar typing. I will not explain the reasons behind this here, because they have been covered extensively in the previous threads and I no longer have the patience for such heavily prejudiced discussions. As such this mail is really an explanation why I am voting for an RFC defaulting to weak types, despite my misgivings with such a typing scheme. A primary appeal of this RFC is that the "strict_types" mode not only influences userland function calls, but also calls to internal functions. I really appreciate the symmetry behind this - a plain strict scalar typing proposal would only cover userland calls, while this also enforces proper type usage with internal ones. This seems very reasonable, as the same arguments in favor of strict scalar types for userland functions apply nearly identically to internal functions as well. Another advantage of this approach is that there are fewer interoperability issues between libraries using strict typing internally and external code not making use of it. A pure strict scalar typing proposal would likely cause severe integration issues between code using scalar types and code not using them at all and as such using relatively unpredictable data types. This issue will not be entirely alleviated by this proposal (primarily due to the lack of generic or semi-generic types), but it will be much more limited and libraries should be able to safely use the strict typing mode without alienating users. Lastly, I would like to talk about cognitive overhead. This RFC uses a per-file typing mode declaration and there may be concerns about having to mentally adjust to different modes being used in different files of a project. While I think this is an important concern, there are two ameliorating factors: a) It is very likely that libraries using strict scalar types will use them in the entire project rather than having a mix of different modes in different files. Similarly applications will likely also either be fully strictly typed or have clearly separated front- and backend components where only the latter uses strict scalar types. b) Within one file, this RFC actually removes mental overhead, because type declarations will behave identically for userland and internal functions. You won't have to deal with some functions being liberal and some being strict. Thanks, Nikita
