On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: > On 12/23/11 13:34, "Will Fitch" <will.fi...@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.
Many have expressed this same concern. I'm going to update the patch and RFC to reflect this. If we decide to add a marker/token to indicate allowing null, we will decide after discussing this change. Baby steps.... > > 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). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
