On Dec 22, 2011, at 18:59, "Will Fitch" <will.fi...@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).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
