Re: [VOTE] Scalar Type Hints

Hi, > On 13 Feb 2015, at 16:18, Benjamin Eberlei <kontakt@beberlei.de> wrote: > > Wait i almost forgot, it *does* have an effect on me, especially around callback handling: > > https://gist.github.com/schmittjoh/778e044deacc6f1fe516 > > Essentially callbacks are evaluated in the mode they are called in, not in the one they are > defined. This is correct, yes. This is only going to cause a problem, however, if: * You add type hints despite not knowing what types will be passed * You add type hints for the wrong types In both cases, you have only yourself to blame for your code not working. So, I really don’t think it’s an issue. If you don’t know what types will be passed, why did you add type hints? If you know what types will be passed and added incorrect type hints, why did you expect that to always work? There is of course a third case: the function’s documentation lies and claims the function will call your callback with certain types, and actually passes different types. However, this is not a problem with the RFC, and is something that could happen anyway. At least with this RFC, you might discover the bug in the library more quickly due to getting an error. Anyhow, we could catch such errors prior to call-time by extending the callable typehint to take a parameter list, such that parameter type hints can be checked (with the same rules as used by inheritance). This would solve your problem. Thanks. -- Andrea Faulds http://ajf.me/