I'm sorry but even though I liked that RFC, I'd like to ask about type hinting through annotations. Has anyone considered that? I think that it would be nice because it also docs the functions at the same time.
To be honest I don't know even if that's possible. So, it's just a thought. 2011/12/24 Will Fitch <will.fi...@gmail.com> > 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.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 > >
