Re: Return Type Hinting for Methods RFC

Also, the RFC will be changing tonight/tomorrow'ish to take procedures (functions) into account as well. I know there are many who want to address the additional "types" to hint (e.g. scalar keyword), but I would like to focus discussion of the RFC to its current state - which is to match the state of parameter type hints. On Dec 27, 2011, at 11:19 AM, Dmitri Snytkine wrote: > I think annotations is a completely different topic to be discussed > separately. First the type hinting for variables and return values has to be > supported by the language, including hinting for primitive types. If and > when this is done, then, if annotations are supported natively, maybe these > 2 can be combined. > > > > Dmitri Snytkine > Web Developer > Ultra Logistics, Inc. > Phone: (888) 220-4640 x 2097 > Fax: (888) 795-6642 > E-Mail: dsnytkine@ultralogistics.com > Web: www.ultralogistics.com > > "A Top 100 Logistics I.T. Provider in 2011" > > > -----Original Message----- > From: Jonathan Garcia Lima [mailto:jonathanglima@gmail.com] > Sent: Tuesday, December 27, 2011 11:12 AM > To: PHP Developers Mailing List > Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC > > 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.fitch@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.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). >>> >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >