So, do we mark the return value as string or mixed :) ? Of course, I see now that this probably extends to every single string function. Also, probably my commit needs fixing in light of this cos now I see that if you pass an object with a __toString method then it will do string casting but otherwise it won't... This is becoming a mess, fast: strval(new stdClass)) is a catchable fatal, passing it to substr/strtr causes a warning and a return of NULL. strval(array()) is a notice, passing it to substr/strtr causes a warning and a return of NULL. I am sure there's logic in this just I can't see it. There's certainly a lot to document here...
On Tue, Feb 5, 2013 at 3:50 AM, Ferenc Kovacs <tyr...@gmail.com> wrote: > > > > On Tue, Feb 5, 2013 at 10:45 AM, Karoly Negyesi <kar...@negyesi.net> wrote: >> >> Hi, >> >> So strtr can return FALSE according to current docs and I just >> documented the case where it can return a NULL. >> >> So, do we document it as returning mixed or is it string? I mean, it's >> only mixed when some error is happening. >> >> Best >> >> ChX > > > Hi, > > We have a note on http://www.php.net/manual/en/functions.internal.php > "Note: If the parameters given to a function are not what it expects, such > as passing an array where a string is expected, the return value of the > function is undefined. In this case it will likely return NULL but this is > just a convention, and cannot be relied upon." > We introduced a new parameter parsing API, which made this behavior more > widely supported: > http://php.net/manual/en/migration53.incompatible.php > "The newer internal parameter parsing API has been applied across all the > extensions bundled with PHP 5.3.x. This parameter parsing API causes > functions to return NULL when passed incompatible parameters. There are some > exceptions to this rule, such as the get_class() function, which will > continue to return FALSE on error." > > I think that the current documentation is lacking in this regard, but I'm > not sure which would be the best solution to address this. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu
