On 16 February 2015 at 16:42, 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. > > 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 ? > Note that the accepted timeline for PHP 7 [1] states that we will have three months to "Finalize implementation & testing of new features", after the March deadline. That should give us some time to tie down the actual implementation side of things. Apart from that, it's more a matter of getting an RFC drafted, discussed, voted on, before the March deadline. I, for one, wouldn't mind the vote taking a wee while longer (say, a week or two) if it means we can get this feature added. > > 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 > >
