Scalars will not be supported as type hints. There was talk of a "scalar" token added for validation in that category, but it does NOT need to be supported for return type hinting to be included. Return type hints are following the same logic as parameter type hints and should be considered in that category.
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: dsnytk...@ultralogistics.com > Web: www.ultralogistics.com > > "A Top 100 Logistics I.T. Provider in 2011" > > > -----Original Message----- > From: Jonathan Garcia Lima [mailto:jonathangl...@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.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 >> >> > > > -- > 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
