Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79069
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.207 as permitted sender)
References: <D7C8CEF6-625E-4489-8EFC-8FCAA16302D2@ajf.me> <CAFMT4NodhUcS3f-nnCpxGuR=AA6-g9wTchzeS7faTeu9SSL5xw@mail.gmail.com> <CADajX4Ctcn7HHu_YbxunT1TALbx8Koe1F4pOO_YwjKv5n8=Vgg@mail.gmail.com> <5A250A28-F5C2-4FF1-B144-C19B2220EADC@ajf.me> <CADajX4B0Jj=6TSvWE+aZLYsT8YN3zOAXeO-OGJgh807Xwzoq0w@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CADajX4B0Jj=6TSvWE+aZLYsT8YN3zOAXeO-OGJgh807Xwzoq0w@mail.gmail.com>
Content-Type: text/plain;
	charset=windows-1251
Content-Transfer-Encoding: quoted-printable
Message-ID: <01ECB6B5-2342-467C-89FF-FFAD56CBE39E@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Date: Fri, 21 Nov 2014 09:26:27 +0000
To: Adam Harvey <aharvey@php.net>
Subject: Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions
From: ajf@ajf.me (Andrea Faulds)


> On 21 Nov 2014, at 03:02, Adam Harvey <aharvey@php.net> wrote:
>=20
>> The problem is that it=92s the least bad of the available options.
>=20
> I disagree. To my mind, the best option right now (barring the status
> quo, which realistically I'd prefer) would be the try_* functions
> only. They line up with how ext/standard (and pretty much all of PHP
> other than a smattering of OO functions and SPL) signal errors, and
> avoid duplication. I don't really fancy explaining the difference
> between to_* and try_* in ##php to a new developer.
>=20
> PHP may be a mishmash of undesigned APIs in places, but that doesn't
> mean we should dump fuel on the fire by adding two parallel APIs that
> are named obscurely and differ only in how they signal errors.
>=20
> There's no function in php-src today that throws an exception outside
> of an OO context. (Indeed, if you go through the various classes and
> methods in php-src, I suspect even _in_ an OO context the majority of
> errors are signalled via return values or PHP errors.)
>=20
> Right now, the standard for appropriateness when adding an exception
> is pretty much "is this an error generated in an OO context"? This
> clearly isn't.
>=20
> To be clear: if a way could be designed to do it without shredding BC,
> I'd be ecstatic if we deprecated our current error handling system
> entirely in favour of exceptions in PHP 7. But that's not the standard
> right now, and an unrelated RFC like this isn't the place to make that
> decision.
>=20
> Why would you throw an E_RECOVERABLE_ERROR? The error's been
> signalled: the function returned NULL, rather than an
> int/float/string.

try_ serves a different use case to to_. to_ is mostly supposed to be a last=
 line of defence. The only reason it's any safer than an explicit cast is th=
at it throws an error that will halt execution if it goes unhandled. If you h=
ave to explicitly check for an error, that means people won't, and the aim o=
f making safer casting as convenient as unsafe casting will not have been ac=
hieved. So, the alternative would be an E_RECOVERABLE_ERROR.

try_ exists so you can use the to_ functions in a validation context, where e=
xceptions shouldn't be used for flow control. Of these two sets of functions=
, if I have to get rid of one, it'd be try_.

Also, a special note: to_/try_string is particularly useful if you want to g=
racefully handle casting of objects which lack __toString to a string, one o=
f the only cases currently where an explicit cast can fail. There's currentl=
y no way to do this aside from checking for the existence of __toString, whi=
ch isn't necessarily correct as an internal class can allow casting to strin=
g without defining that method.

--
Andrea Faulds
http://ajf.me/=