Re: Re: [PHP4BETA] cvs: /php4/ext/standard array.c

> On Wed, 29 Mar 2000, Sterling Hughes wrote: > > I agree that every function with return type 'void' should return NULL either on > > success or on failure from non-user errors, however, I think when the user does something wrong (in > > the case of array.c most of the return values changed are for invalid types), the program should > > whine and bitch in every possible way, including returning false. > > > > As far as array.c is concerned many of the functions that are prototyped as void (such as > > rsort or sort or any of the sort functions actually) return true on success, therefore > > shouldn't it make sense that they return false on failure? > > > > If we decide to change the return value back to NULL on failure, perhaps we should stop > > the functions from returning true as well. > > I don't know.. If the function is void, then it should be 'void', i.e. > return NULL. If you return TRUE/FALSE then it's not 'void' anymore, it's > 'bool' and the return value indicates success or failure. But that's > inconsistent because other functions may return real TRUE/FALSE values > that have nothing to do with success/failure. > I think that the functions should be left returning TRUE and FALSE because scripts in PHP3 that might work like this: if (sort($ar)) { // Array is sorted } else { // Array is not sorted } Will not work if the return value becomes un-equivacably NULL, and having a function return NULL on failure and TRUE on success doesn't make to much sense in my opinion. Sterling P.s.: Perhaps we might not document the functions as returning 'void' but rather as 'bool', the docs for ksort and krsort already sort of do this (they claim it returns 'int').