Re: Return Type Hinting for Methods RFC

On Dec 22, 2011, at 18:59, "Will Fitch" <will.fitch@gmail.com> wrote: > Would you prefer to allow methods with type hinted return values to return null at will, or add > a marker noting that it *may* return null? My preference would be to have a marker, and when null is not allowed, if the function tries to return it (or fails to return anything at all), then an error is raised or exception thrown. This behavior would be great for those cases where you're trying to protect against situations that theoretically should be impossible, much like the role of assertions. The marker then would handle those situations where you want to explicitly allow null return values based on routine inputs. A common problem with PHP is that you just don't know what a function might do if you don't look over its code or it's docs. The marker makes one part of its behavior explicit, thus abbreviating the guessing game. (Not to mention when the docs themselves errantly fail to mention that a function can return types other than the obvious....) In fitting with the PHP way, perhaps it would make sense that the marker indicates not just that null may be returned, but that any type may be returned. This would allow, say, returning false or -1 instead of null. Or maybe it's better just to allow indication of multiple types and have the marker be for just for null. > public ArrayIterator getIterator() I would really, really prefer to always have the 'function' keyword be present. It offers something to scan for when quickly reviewing code, it makes it easier to do search-and-replace operations on functions, and it allows text editors that don't have the full-blown lexical analyzer of an IDE to still be able to pick out all the functions and offer the user an easy navigation feature. I do, however, quite like the idea of putting the return type at the end of the function declaration. I've always disliked the way C and its derivatives stick the return type at the beginning (along with an ever-increasing list of other keywords), since it makes it harder to quickly scan the code by forcing a more thorough mental parsing instead of just letting you snap your eye to a known position. As for an operator suggestion, one precedent I can think of is from Pascal, which uses a colon: function GetName(): string This puts the result type at the end where you always know right where to look for it without mental parsing, and it reads naturally in that the effect (the result) is listed after the cause (the function). And, at least for English writers, the colon's purpose is intuitive because of its use in English grammar. Finally, PHP doesn't already use the single colon for anything that I can think of off-hand. I'd also like to comment on the use of type checking in PHP. I completely agree that having more broad checking available in the language would be a great thing. However, I also understand the criticisms against it. What if, instead of specifying strict scalar types, like int, one could specify a type class (not in the OOP sense)? The concept has already been alluded to, but I don't think anyone has run with the idea yet. I'm thinking here of things like PHP's filter functions or the character classes in regular expressions. So you might specify a type of 'digits', which would allow anything that consists only of the numbers 0-9, or which could losslessly (by which I mean reversible to the same starting value) be cast to such a beast, equivalent to this monstrosity that I frequently find myself using: if (!\ctype_digit((string)$parameterValue) { ... } (I think it was Stas that mentioned using is_numeric() for things like this, but I find that function virtually useless since it unconditionally allows oddities like hex values that you typically don't want to allow. The other alternative, is_int(), forces the very type of strict checking--and thus, calling-side casting--that we all wish to avoid.) Allowing specifications of types that are more flexible than the base scalars would enable type checking but retain the advantages that a dynamic language offers. That said, I suspect that no one is talking about this option because it's been discussed a million times in the past and deemed a bad and/or unworkable solution for whatever reasons. :-) -- Bob Williams 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).