Hi Dmitry De : Dmitry Stogov [mailto:dmi...@zend.com]
> 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. Yes, but that's not exactly what I had in mind. I thought we could just use it as a base, and add features that, for any reason, will be much harder to implement in the future. However, most of the work I want to do deals with ZPP macros, which are not so complex. And userspace type hints follow ZPP rules, so ZPP changes will apply to internal and userspace functions automatically. The first thing to do is restricting authorized parsing conversions (ZPP *and* zend_parse_parameters must matc here) to get approval from strict-typing fans (tan(1) and curl use cases must be solved first). Then, define multi-type conversion rules and implement that in ZPP (just ZPP, not zend_parse_parameters). Once it is available in ZPP, internal functions will migrate from Z_PARAM_ZVAL at their own pace but the mechanism must exist before functions can gradually use it. I would really like to implement multi-type support now. IMO, it is one of the most useful characteristics I expect from type hinting. Multi-typed argument are natural in PHP from the beginning and should have been part of the RFC from its beginning too. If people start describing multi-type args as 'mixed', which is not the same information, they won't come back and do the work again with more precise types, asking whether each 'mixed' is a 'real' mixed or just a placeholder waiting for us to implement the rest. I am especially concerned with the fact that a good part of userspace function arguments will be just impossible to type, except as 'mixed', which is not accurate in most cases. 3 lines above the argument declaration, a phpdoc comment says that $arg is 'string|array', but the user cannot transmit the information to the engine... I know it may be a question of time but it saddens me. I propose you implement the parser/userspace part (I don't know what remains to be done) and I write and implement ZPP restrictions and multi-type support. I'll try to define ZPP restrictions (single type) tonight. I'll also read the 0.1 RFC again and send comments if I have some. I already know that I want to add the 'resource' type because Andrea's argument is fake, IMO (and it would make it the only type without a hint). >>- 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. Would feature freeze also apply to such work ? Before I write anything, what do you think of suppressing conversions to/from IS_NULL in zpp (provided we support multi-typed args, of course ? Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
