2015-02-16 18:42 GMT+02:00 François Laupretre <franc...@php.net>:
> 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. > > Sounds quite reasonable and level headed. I'm gonna contact you off-list to assist in any way I can, i'll be damned if RFC fails 4th time...