On Sat, Apr 29, 2017 at 10:01 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > That mix sounds very reasonable. Does it still make you go "eww" to suggest > that those settings that don't deserve their own method, and take a boolean > argument rather than a string or int, could have a different method, such as > setFlag? Because that's really all I was suggesting: a more visible > distinction that said "this method always takes a boolean", rather than > "this method must be given a boolean if given this, that, or the other". > It certainly seems unnecessary. setBool(), setInt(), setOffset(), setString(), versus setOption() is imposing a design detail on the consumer that shouldn't be relevant to them. In fact, in weak mode, it becomes especially irrelevant to know the difference between an int and a bool setting. Specifying type in the method name is essentially imposing a cognitive form of strict mode on those who don't want it.
> Meanwhile, I'll repeat that if there really is precedent for functions > validating their arguments based on both strict_types mode and the value of > some other parameter, then my concern (mostly) evaporates, and I suspect > others' might also. I just checked through the thread and RFC, and can't see > these examples being named, so I would very much appreciate a specific > example. > Not on *both* strict mode and the value of another parameter, there's very little application of strict mode throughout the codebase because strict mode is new. What there are precedents of, and what I was responding to in your earlier email, was the idea that an arguments type can vary based on the type and/or number of other arguments. This precedent exists in the pg_*() methods as I already pointed you at, and a quick grep shows stream_context_set_option(), and a particularly fascinating "signature" in intlcal_set(). > Perhaps the precedents seem obvious to you, and that's why this whole > conversation is frustrating you? It definitely feels like there is some > miscommunication, because you seem surprised that people have any concerns > at all. > I'm not surprised that there are concerns, I'm just shocked that the concerns are so poorly founded. Arguments I've heard so far fall into two categories. 1. If the parameter isn't reflectable, then it shouldn't be subject to enforcement. This argument holds no water because internal functions can only reflect array or object type hints, yet we enforce other types routinely. 2. Type enforcement should not depend on the declare(strict_types=1); directive. This argument is ridiculous on the face of it, since that's precisely what that declare() directive was designed for. The fact that the type being enforced is dependent on another arg's value is an irrelevant implementation detail. Think about the user's experience here. Bob wants to call curl_setopt($ch, CURLOPT_RETURNTRANSFER, $value); Bob expects $value to be validated and used as a boolean. If Bob has strict_types set, he expects an exception if $value isn't a bool, if it's not set, he expects the value to be quietly converted (if possible within type affinity). -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
