Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75446
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.199 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me>
Date: Mon, 14 Jul 2014 13:58:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me>
To: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: ajf@ajf.me (Andrea Faulds)

Hello again,

One of the issues with the RFC as it stands is how to handle bool =
casting. While int, float and string only allow lossless casting (with =
the exception of objects, but we can=92t really do anything about that), =
bool=92s behaviour at the moment is quite different. I don=92t think it =
makes sense so I won=92t discuss the current behaviour, only possible =
new ones.

One option is simply to forget about being lossless and make the bool =
type hint accept any value, meaning any truthy value or any falsey value =
would yield what is expected without error. This would ensure that if =
some stupid programmer (like myself ;) has passed in a non-boolean =
truthy/falsey value to your function, it=92ll be handled correctly. It =
would mean all your bit hacks ($foo & FLAG etc.) would work, anything =
you got from $_GET (e.g. ?foobar=3D1). However, this is unlikely to =
catch bugs in code, because literally any PHP value would work. For that =
reason, I=92m not sure this is the way forward.

Another option is go completely strict and allow only boolean values, =
failing everything else. This would be unlike the int, float and string =
hints, which are flexible and cast, but would be more helpful for =
catching bugs. However, not casting at all isn=92t very =93PHP-like=94, =
and forcing people to manually cast with (bool) might not be ideal. If =
we were to go for this one, I might also accept objects casting to bool =
(which the default handler does), because I don=92t want to stop =
extension developers from making bool-like objects if they so please.

The final option I=92m thinking about is a limited set of values. TRUE, =
FALSE and NULL would be accepted, along with the integer and float =
values 1 and 0 (which are the int/float TRUE and FALSE cast to, =
respectively), =911=92 and the empty string (which are the string values =
TRUE and FALSE cast to), and =910=92 (which (string)(int)FALSE would =
give you), along with objects casting to boolean. It=92s not a perfect =
solution, but I currently feel that this is the most sensible option bar =
going for full strictness.

I=92m not really decided, however. Every time I try to think about this, =
I usually end up going in circles. Anthony doesn=92t seem to be decided =
either. Hence I=92m putting this up for discussion.

What are your thoughts?

--
Andrea Faulds
http://ajf.me/