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. 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
