On Mon, Feb 16, 2015 at 9:42 AM, 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 ? > > 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.
I have a sum types RFC that isn't ready for discussion. However, since you have mentioned the functionality it here is the preliminary RFC: https://wiki.php.net/rfc/sum_types. Also, I know people REALLY want scalar types in PHP 7.0 but honestly all we need to do is reserve the keywords so there is no BC impact and then we can do it at any point during the PHP 7 lifecycle. This is my preferred course of action, because right now this internals mailing list is in HIGH STRESS MODE. I would rather just take the action of reserving the types so it can be done in 7.1 (or 7.2 or even if it's never, I would prefer to reserve these words). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php