Hi,
On Jan 4, 2015 3:10 AM, "Andrea Faulds" <a...@ajf.me> wrote:
>
> 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.
Hm. It sounds bad. There is a data loss, a notice must be raised. This is
exactly the kind of magic conversion that should not happen for arguments.
> 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.
Right, but this is what I would expect. Am I the only one?
