On Sat, Apr 29, 2017 at 11:11 AM, Fleshgrinder <p...@fleshgrinder.com> wrote: > Let me be Bob, and my assumption would be completely different. I expect > that internals behave the same as userland implementations. I know that > this is not the case in every circumstance, but those where this > assumption does not hold true are meant to cover very special edge > cases, like GMP. I consider many others as being ugly hacks. > Your example of GMP can't be simply dismissed as "a special edge case", it's precisely true that internals does not always follow the same rules as userspace and often it breaks those rules for very good reason.
> I expect strict types to affect the arguments I pass to a routine, not > more, not less. > Agreed. And that's what this proposal suggests. If I took at your word here, I would expect you to support this RFC. > In other words, I consult the docs and if the signature states an > expected type for a parameter of a routine, I expect strict types to > validate that for me, not more, not less. The docs of `curl_setopt` > states `mixed` for `$value` and that is what I expect. > > https://php.net/curl-setopt > Again, you're weakening your own position. The PHP manual page for curl_setopt() GOES ON to state the per-option types which should be passed for $value. I expect strict types to validate that for me, not more, not less. The fact that you fail to read past the first line of the manual page doesn't invalidate the function's *total* signature. > This does not mean that it is not allowed to throw an exception if the > value is of another type, but it must not use strict types to determine > its mode. Simply because I cannot do the same in userland. > Again, false. The fact* that something can not be done in userland does not preclude doing it in internals. You mentioned one such case at the start of your reply and there are plenty others. -Sara * Pedantically: This is not even true. Using backtraces and some simple hacks, it's quite possible to determine the caller's strict_types setting from userspace. But that's going off on a tangent... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
