Hi, > > De : Arvids Godjuks [mailto:arvids.godj...@gmail.com] > > The 0.1 RFC version was mentioned a lot as a good compromise by many > people > and had major support. > Maybe someone competent could pick it up, make necessary adjustments > that > where required and let people vote on it? Start with small steps - get the > weak type hints into the language first, see how it gets used and then we > can always add strict type hints if there is a need/desire to do that. > > That way we finally get type hints into the language, and those wanting the > strict variety have all the opportunities in the world to add them at a > later release with proper discussion and development time.
That's what I am planning. If I write an RFC, it will be based on Andrea's 0.1/0.2 version, and won't propose different modes. The problem is that the previous controversial RFC focused people on weak vs strict typing, while we should have explored other technical concerns. Here are the main ones I see : - the fact that the RFC supports single types only, like the previous 'return type' RFC. While it is easier to implement, it opens several issues as multiply-typed arguments are an integral part of the PHP language (mostly completeness and compatibility with internal function hinting). If we want to support multiple types the same way for internal and userspace functions, we must extend the ZPP layer to support it. - the mechanism to check for type hints on internal functions, while easy to implement, is not sufficient, as a lot of internal functions get a bare zval from the parsing system and then convert it by themselves. With the proposed mechanism, there's no possible hinting on such argument, which will make the implementation different from the documentation. Even if the check is done by the function body, it won't be done in a consistent way with type hinting checks and won't raise a similar error. As most cases are related to multiply-typed args, the solution is in adding multiply-typed support to ZPP. Multiply-typed support needs to redefine scalar conversion rules, to take care of the target type being a combination of single types. - We need to define the appropriate extension to Reflection parameters/return type. That's not complex, but it takes time. - Other changes I'd like to propose are exposed in Bob Weinand's article, at https://gist.github.com/bwoebi/b4c5564388ecd004ba96. The article explains how restricting weak conversion possibilities would make strict typing almost useless. Changes include forbidding bool to int/float or '7years' to int. This cannot be left for future additions as BC breaks will make it impossible. To remain consistent between userspace/internal functions, this must also be done at the ZPP level. - Using bare class names as type hints is a potential issue too, as it makes reserved keywords and class names share the same naming space. I think we should deprecate the use of class names as type hints in favor of 'object(class-name)'. If we don't do that, every future addition of a type hint keyword will cause a BC break (and will be practically impossible). - Additional 'hybrid' types like 'numeric' and 'mixed' should be also provided. So, most features I have in mind are really 'now or never'. My main concern, anyway, is with March 15 announced feature freeze. If we need a vote by this date, it's impossible. And planning such BC for 7.1 is probably unrealistic because of the huge syntax additions and BC breaks it brings. So, if it's too late for an inclusion in 7.0, I think I'll give up. So, could someone confirm what 'feature freeze' exactly means ? Regards François The main issues are completeness (we can give hints for some cases, but not for others) and, more important, the compatibility with internal functions. As Andrea herself agreed, her mechanism for type hinting on internal functions is not sufficient. Just using the ZPP macros, as they exist today, won't work as a lot of internal functions get a bare zval and then convert it by themselves. So, in this case, we would check nothing. So, an argument described as 'string|array' in the documentation, wouldn't produce the same sort of error when sent an object, than its friend, described as 'string'. This is not consistent and will open a lot of side effects if it is left out of the type hint layer. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
