> -----Original Message----- > From: Christoph Becker [mailto:cmbecker69@xxxxxx] > Sent: Thursday, March 06, 2014 1:31 PM > To: Robert Stoll; 'Sebastian Krebs' > Cc: 'PHP General List' > Subject: Re: Mixed return type - boolean and array/resource/closure or object > > Robert Stoll wrote: > > >> -----Original Message----- > >> From: Christoph Becker [mailto:cmbecker69@xxxxxx] > >> Sent: Wednesday, March 05, 2014 5:37 PM > >> To: Robert Stoll; 'Sebastian Krebs' > >> Cc: 'PHP General List' > >> Subject: Re: Mixed return type - boolean and array/resource/closure or object > >> > >> Robert Stoll wrote: > >> > >>> Nevertheless, the signature in the documentation implies that > >>> date_create() returns always DateTime. I already submitted a patch to > >>> change it to mixed :) > >> > >> IMHO, the signature is fine, as false is returned only in *exceptional* > >> cases. To be strict, changing the return type to mixed had to be done > >> for (nearly) *all* functions, because several may return false in error > >> cases, and many will return null when wrong arguments are passed. > > > > I see your point. But IMO it is confusing that something else is returned than mentioned in the signature. I always take > > strpos as a reference (it has mixed as return type). Yet, mixed is not really precise and I think it would be better to > > have something like "int|false" or a shorter form, maybe "int!" to indicate that either int or false is returned. > > > > Changing strpos to int would be wrong IMO. I want to see at one glance from the signature of the function what it > > returns. As I said mixed is not ideal either since I have to scroll down to 'Return Values' but better than confusing > > me. > > > > About null, I see null as part of an object type. I know that many people would not agree on this one but for me it > > makes sense. > > I was referring to the following note regarding built-in functions[1]: > > | 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. > > [1] <http://www.php.net/manual/en/functions.internal.php> > > -- > Christoph M. Becker Cheers, I wasn't aware of this fact. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
