On Tue, Feb 5, 2013 at 2:56 PM, Peter Cowburn <petercowb...@gmail.com>wrote:
> On 5 February 2013 11:50, Ferenc Kovacs <tyr...@gmail.com> wrote: > > > > 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. > > > > Whatever happens, we don't want to start adding phrases like "this > function will return null and issue an E_WARNING if you feed rubbish > into it" to any (nearly all!) functions. Expanding upon that short > paragraph mentioned above might be nice, but I would really dislike > for us to start "fixing" almost every single function's return types > (they would all return "mixed"). I'm sure we've discussed this > on-list previously, I'll take a look at the history. > Yeah, this is why I wrote that I'm not sure how to fix. But if we could figure out a way where we could get more visibility to this behaviour without false-positives and the burden of manually going through all of the methods and like/mention that note, then I think it would be better than the current situation. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
