> De : Zeev Suraski [mailto:z...@zend.com] > > Even though that's not what I meant when I sent my proposal in the > morning,
Sorry, I was not clear enough : it was my position only. > I've been wondering about the same thing (also with the feedback from > Dmitry). Can go an extra step from both directions, and come up with a rule > set that is stricter than the currently proposed weak hinting, but not as > strict as the currently proposed strict hinting? > Key challenge I see with that is that scalar type hinting would go farther > apart from our implicit casting rules. However, the current RFC already > aligned with ZPP as opposed to implicit casting rules (e.g. by rejecting > "Apple" as an int). Choosing between that and having two separate modes, I > think that's the better option. ZPP already chose a while ago to implement a much restricted conversion set from convert_to_xxx() rules. The objective is not the same, as casting must be as permissive as possible (we could discuss that in the future too...). I hope we all agree to keep scalar type hinting aligned on ZPP rules. I also think we all agree, while implicitely, on the ruleset changes we're expecting. I am currently writing this down, so that we have a written base to discuss. Just one detail, to be sure we are in sync : new conversion rules will remain in sync between zend_parse_parameters() and zpp, while future additional types will be defined in zpp only. I assume we are OK to refuse extending the zend_parse_parameters() format in the future. > I think that practically speaking, that is incorrect, at least from my > experience with PHP developers. They do differentiate between built-in > functions and userland functions. There are some fundamental differences > between the two (being able to find their code, step into them in a > debugger, find docs on php.net, etc.). > As I mentioned earlier, the fundamental difference between built-in > functions and userland functions in the context of our discussion is that if > we introduce userland type hints, nothing happens before people change > their > code, and make (hopefully) informed decisions about what type hints to add, > if any. No such luck with built-in functions, which have type information > associated, built collectively over the last two decades. As Rasmus > demonstrated, flipping that switch on for built-in functions results in a > lot of work to 'clean' the code up, but you end up with having code that's > not necessarily any better. That said, it's quite possible that the > situation will be much improved if & when we implement the less-strict rules > we're proposing here, which would accept "32" as an integer or 37 as a > float. I fully agree with you and Rasmus. Strict typing, as defined in 0.3, does not fit with internal functions. To summarize, we have two options : - differentiate behavior and run weak checks on internal functions, even if strict switch is on. - attempt to get back to a single-mode mechanism, which would keep both worlds in sync. I definitely prefer to explore the second one. > If we still see that employing the strict(er) rules is very noisy with > internal functions, a more appropriate option may be introducing new types > into ZPP, that would correspond to the new rules we introduce in the > userland type hints, Why not, but let's first try avoiding it first, as we'll bikeshed during weeks on the syntax for new keywords. Remember that class names share the same naming space as type hint keywords. So, defining new keywords will lead to endless discussions. And stating, as I heard, that we just have to use lowercase-only keywords, is not serious. That's a little off-topic here, but I would also propose to deprecate using bare class names as type hints from 7.0. That's a big BC change and a lot will hate that, but the issue was created when the 'array' type hint was added, and we need to fix it (proposing an alternate syntax like 'object(classname)'). As long as we support bare class names, adding a new type is almost impossible and typedef is *totally* impossible. It's just deprecating, but the impact is such that it can come with a major version only. A smoother path can be to introduce the alternate syntax in 7.0, then deprecate in 7.1 or 7.2. It will take more time but it's probably better. > > union types can be kept for the future if we don't go the > > nullable road, as it would be too confusing making 'string|null' and > > '?string' > > synonyms. > > I think we all agree about that. Fine :) ! Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
