> -----Original Message----- > From: Andrey Andreev [mailto:n...@devilix.net] > Sent: Tuesday, February 17, 2015 4:49 PM > To: Zeev Suraski > Cc: franc...@php.net; Sara Golemon; PHP internals > Subject: Re: [PHP-DEV] Reviving scalar type hints > > Hi, > > On Tue, Feb 17, 2015 at 3:33 PM, Zeev Suraski <z...@zend.com> wrote: > > I agree. It's more of a question of eliminating potentially dangerous > > conversions than just being lossless. > > > > Agreed as well. However, while bool -> int conversion one of the reasons > why many people want strict type-hints, it also often makes sense and is > quite widespread. There's no silver bullet for that problem.
I'm not sure we need a silver bullet. If the conversion and acceptance rules are clear and reasonable, it's an entirely valid outcome that in cases where both int and bool are equally acceptable, you won't use a type hint but rather explicitly cast to int inside the function. > But is it the best solution? The dual-mode approach was suggested because > there is need and demand for *two* kinds of type-hinting. Most of the > controversy and criticism came from the fact that introduces a switchable > mode, while most of the praise received was due to somebody finally > proposing *both* solutions at the same time. Every option has pros and cons. Since it's clear beyond a reasonable doubt that we can't all agree on purely weak type hints and equally on purely strict type hints, it becomes a question of what is the right compromise. Adding both - which at least from my point of view has major drawbacks (too prominent zval.type exposure; complexity of two systems; internal functions issue). Creating something in between that would handle most if not all of the use cases the strict camp brought up, while not (IMHO) overly focusing on zval.type and making things a lot more noisy/complex for built-in functions - is a better direction, whose advantage - I think - outweigh its disadvantages. > > 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, and requiring extension authors to explicitly > > move to them where they believe it's appropriate. That will allow > > extension authors to make their choice regarding their APIs, similarly > > to the process that will happen in userland. > > > > And that brings us back to square one ... Expose only 1 tool to userland, > but > then give two options to the much less-populated crowd of extension > developers. That doesn't make sense to me. First, let us hope that the situation will be much better to a level that we don't need to go in that direction :) But that said, I don't quite see it in the same way. Internal functions already commonly use a lot more advanced type checking than is commonly found in userland functions. Functions that behave differently depending on the type of argument you pass, on the number of arguments, etc. While technically it's possible to achieve in userland, it's a lot less common. So while I do see an issue here, I don't think it's *that* bad if it has to come to that. Unless we find out our rules work nicely out of the box for internal functions (which I'm still somewhat hopeful for) - there's no way to reconcile the fact that internal functions come with this long history of having detailed type data, while userland functions do not... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
