Re: Return Type Hinting for Methods RFC

From: Date: Sat, 24 Dec 2011 22:16:08 +0000
Subject: Re: Return Type Hinting for Methods RFC
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-57093@lists.php.net to get a copy of this message
The RFC and patch has been updated to include the nullable functionality that addresses the concerns mentioned by Stas. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 5:02 PM, Will Fitch wrote: > 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). >

« previous php.internals (#57093) next »