Hi Andrey, > On 14 Jan 2015, at 11:10, Andrey Andreev <n...@devilix.net> wrote: > > I don't understand why it should be a bad thing that the API author > forces rules on the consumer. The opposite is IMO fundamental to the > concept of an API - the rules specified by the author are a contract > that the consumer agrees to, and which allows for the whole thing to > work properly. > > In this form, I don't get any benefit from strict type checks, because > I only want them so that writing foo(int $bar) guarantees me that the > caller *passed* an integer. Instead, I'd have to NOT use a type hint, > and instead do an is_int($bar) check inside ... this beats the whole > purpose.
Why? What is wrong with a caller choosing to use weak type hints? Either way you receive an integer. > This caller-controlled switch very much reminds me of > mbstring.func_overload, which I didn't care much for, until one day I > saw how it breaks all crypto code that authors had otherwise written > very carefully. > > I prefer Julien's (int) $weak vs. int $strong syntax better (which is > what I've always wanted), but I don't care much if it's a declare() > statement, just as long as the author controls the behavior. > And while I'm on that - thank you for this proposal (specifically the > 0.2 version), Andrea. Finally an RFC that allows both weak and strict > scalar type checks instead of the "can't go in both directions" > nonsense that has blocked this feature for years. I don’t like going in both directions if I’ll have to deal with both at the same time. I want consistency. Either everything weak or everything strict. That’s why I like this approach. At least within a single file, everything will follow the same approach, rather than it being mix-and-match. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
