Re: [RFC] Scalar Type Hints

Hi Sebastian, > On 3 Jan 2015, at 19:46, Sebastian B.-Hagensen <sbj.ml.read@gmail.com> wrote: >> >> Yeah, I don’t like this behaviour much. I want to avoid inconsistency with the behaviour >> of extension functions (i.e. zend_parse_parameters) where possible, though. Since this has come up >> so much, I should probably make an RFC to change this aspect of ZPP’s behaviour. > > That RFC should probably be voted on before this RFC proceeds into voting. That would be the idea. > After skimming through the RFC I'm unsure what the following code would produce: > > function test(int $a, int $b) {} > > test("10.4", 10.6); > > If a warning/notice is raised, fine. If it will just result in $a === > (int)10 && $b ===(int)10 : The first argument would be converted to 10 and a notice (“Non well formed numeric string”). The second would also be converted to 10, but silently. I agree with your sentiments about data loss, but I am reluctant to deviate much from the behaviour of internal functions to avoid the inconsistency that plagued the previous RFC. > If type annotations wouldn't go beyond the safety that php currently > provides by converting in specific contexts and casting what is the > benefit in adding them? They’re still much safer than what we currently have. An unhinted parameter will accept anything. A scalar hinted parameter won’t accept non-scalars, and will only accept certain scalars. Plus, they also avoid the need to use things like docblocks for many functions where merely adding types would make them self-explanatory. Thanks. -- Andrea Faulds http://ajf.me/