Hi Sebastian,
> On 3 Jan 2015, at 19:46, Sebastian B.-Hagensen <sbj.ml.r...@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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
