Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57056
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thesba.com designates 208.106.205.210 as permitted sender)
To: Will Fitch <will.fitch@gmail.com>
CC: Stas Malyshev <smalyshev@sugarcrm.com>, PHP Developers Mailing List
	<internals@lists.php.net>, =?iso-8859-1?Q?=C1ngel_Gonz=E1lez?=
	<keisial@gmail.com>
Date: Fri, 23 Dec 2011 01:30:42 -0700
Thread-Topic: [PHP-DEV] Return Type Hinting for Methods RFC
Thread-Index: AczBTSlSw/23UYgNTKiGgxEUmR0fYQ==
Message-ID: <76AE524A-69EE-4AEF-8621-2AE2EC9A358B@newtekemail.com>
References: <2095305E-D4E3-4D7E-8218-32EE99688E0C@GMAIL.COM>
 <CAF+90c-Wtok1fnVxokYUFQhbYnMcNDwWWT63F8NDp+JnxCDMew@mail.gmail.com>
 <2C90FB94-38C4-4270-8C6A-B89304BA8ED8@gmail.com>
 <CAEZPtU6gneOOehrsz-qVifmNxg6tnyLt9hqfnAwKZmfpXdeC9Q@mail.gmail.com>
 <159A7CA2-8561-40DA-9434-CAAE12304DDB@gmail.com>
 <4EF3B56A.4040809@gmail.com> <-2451498990672032588@unknownmsgid>
 <4EF3BD21.2040301@sugarcrm.com> <-6952580475866195972@unknownmsgid>
 <4EF3C7F7.9010404@sugarcrm.com> <4841689055873111589@unknownmsgid>
 <4EF3D18B.7040900@sugarcrm.com>
 <11CFB4E4-F2DA-4766-AA23-D08180C3910B@gmail.com>
In-Reply-To: <11CFB4E4-F2DA-4766-AA23-D08180C3910B@gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
From: rewilliams@thesba.com (Robert Williams)

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 retur=
n 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 t=
he function tries to return it (or fails to return anything at all), then a=
n error is raised or exception thrown. This behavior would be great for tho=
se cases where you're trying to protect against situations that theoretical=
ly should be impossible, much like the role of assertions. The marker then =
would handle those situations where you want to explicitly allow null retur=
n 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 men=
tion 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 in=
dicates not just that null may be returned, but that any type may be return=
ed. 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 pres=
ent. 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 t=
ext editors that don't have the full-blown lexical analyzer of an IDE to st=
ill be able to pick out all the functions and offer the user an easy naviga=
tion 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 derivativ=
es stick the return type at the beginning (along with an ever-increasing li=
st 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 yo=
ur 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 l=
ook for it without mental parsing, and it reads naturally in that the effec=
t (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 Eng=
lish grammar. Finally, PHP doesn't already use the single colon for anythin=
g that I can think of off-hand.

I'd also like to comment on the use of type checking in PHP. I completely a=
gree that having more broad checking available in the language would be a g=
reat thing. However, I also understand the criticisms against it. What if, =
instead of specifying strict scalar types, like int, one could specify a ty=
pe class (not in the OOP sense)? The concept has already been alluded to, b=
ut I don't think anyone has run with the idea yet. I'm thinking here of thi=
ngs like PHP's filter functions or the character classes in regular express=
ions. So you might specify a type of 'digits', which would allow anything t=
hat 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, equiv=
alent 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 allow=
s oddities like hex values that you typically don't want to allow. The othe=
r 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 scala=
rs would enable type checking but retain the advantages that a dynamic lang=
uage 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 unworkab=
le 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 d=
elete this e-mail, including attachments without reading or saving them in =
any manner. The unauthorized use, dissemination, distribution, or reproduct=
ion of this e-mail, including attachments, is prohibited and may be unlawfu=
l. If you have received this email in error, please notify us immediately b=
y e-mail or telephone and delete the e-mail and the attachments (if any).