On Mon, Feb 16, 2015 at 7:42 PM, François Laupretre <franc...@php.net> wrote:
> 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. > I would propose exactly Andrea's 0.1. Most people were agree to support weak type hints by default. This proposal won't prevent feature addition of optional strict type hints. All are tired from endless arguing. > 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. > this is not a big technical problem. - 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. > I wouldn't rise this question. Lets it work as is for now. > - We need to define the appropriate extension to Reflection > parameters/return type. That's not complex, but it takes time. > It's a subject for separate more or less obvious RFC. > - 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. > Lets go forward by small steps. If we would do it before we would already got all the features. We may restrict ZPP rules by next RFC. I'll most probably support it. The same for the rest. Thanks. Dmitry. > - 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 > >
