Re: Return Type Hinting for Methods RFC

I have updated the RFC and patch to reflect not allowing null to be returned unconditionally. With the current patch, I have not added any type of indicator to allow null to be returned at all. This will allow us to discuss things one at a time and determine whether we actually want an indicator added. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: > On 12/23/11 13:34, "Will Fitch" <will.fitch@gmail.com> wrote: > > >> There's still the matter of whether allowing null to be returned, >> regardless of the situation, or using another token to identify that >> it could return null. I'd like to know what others think. I see Stas' >> argument that you'll still have to check, but I'm not so sure that is >> such a bad thing. > > I see it as a very bad thing, for two reasons: > > 1) Unconditionally allowing null to be returned takes away an element of > control. You can't get away from error handling, but it's nice to be able > to handle errors how you want. Having nulls thrown at you at any time > means you have to be ready to handle them at any time, rather than > handling them off in a separate area where you have taken the time to > properly prepare for them. This makes for a lot more redundant code > unrelated to the core functionality of the code, and it kills much of the > utility of things like fluent interfaces. > > 2) With type-hinted parameters, the choice has already been made not to > allow null values at any time. Rather, the programmer must explicitly > allow them in the parameter declaration. Doing the same with return types > would provide an important bit of consistency. > > > Regards, > > Bob > > -- > Robert E. Williams, Jr. > Associate Vice President of Software Development > Newtek Businesss Services, Inc. -- The Small Business Authority > https://www.newtekreferrals.com/rewjr > http://www.thesba.com/ > > > > > > > > Notice: This communication, including attachments, may contain information that is > confidential. It constitutes non-public information intended to be conveyed only to the designated > recipient(s). If the reader or recipient of this communication is not the intended recipient, an > employee or agent of the intended recipient who is responsible for delivering it to the intended > recipient, or if you believe that you have received this communication in error, please notify the > sender immediately by return e-mail and promptly delete this e-mail, including attachments without > reading or saving them in any manner. The unauthorized use, dissemination, distribution, or > reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have > received this email in error, please notify us immediately by e-mail or telephone and delete the > e-mail and the attachments (if any).