Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79015
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.245 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <CAFMT4NodhUcS3f-nnCpxGuR=AA6-g9wTchzeS7faTeu9SSL5xw@mail.gmail.com>
Date: Wed, 19 Nov 2014 22:05:52 +0000
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <67A212FE-0051-4DEA-B1BC-AB3CA16CF4B5@ajf.me>
References: <D7C8CEF6-625E-4489-8EFC-8FCAA16302D2@ajf.me> <CAFMT4NodhUcS3f-nnCpxGuR=AA6-g9wTchzeS7faTeu9SSL5xw@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Subject: Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions
From: ajf@ajf.me (Andrea Faulds)


> On 19 Nov 2014, at 21:57, Levi Morrison <levim@php.net> wrote:
>=20
>> Since some things might have changed since you last read the RFC, I =
encourage you to read through it again. If there are any questions which =
have not yet been covered on the mailing list, feel free to ask them.
>=20
>  - The RFC does not address how this is different from
> FILTER_VALIDATE_* from ext/filter. I know there was a mention of this
> on the mailing list, but the RFC should say why a tool that already
> exists to solve this kind of problem is insufficient, especially when
> it is enabled by default.

Yes, I suppose that=E2=80=99s a failing of it just now. But to address =
this:

1) It throws exceptions

2) It is much shorter and more convenient (which is important if we=E2=80=99=
re to discourage (int), (float) use)

3) to_/try_int() and to_/try_float() don't convert the argument to a =
string in order to convert

>  - PHP suffers a lot from function bloat and this RFC provides
> multiple functions that do the same thing but differ only in how they
> handle errors. A simple validation of "can this be safely cast to an
> integer without dataloss?" avoid the issue entirely and would be fewer
> functions.

No, no it would not avoid the issue. We had this before with error =
return values, which are essentially the same as your proposal. People =
didn=E2=80=99t like only covering one use case. I didn=E2=80=99t like =
that. Yes, you can write a wrapper function for a validation function =
that throws an exception. You also could write one for the error return =
value function. It=E2=80=99s equally objectionable.

Secondly, merely =E2=80=9Cvalidating=E2=80=9D and not converting means =
you must then convert after validating. However, the process of =
validating involves converting it. So you=E2=80=99re doing the same =
thing twice, essentially, for no conceivable gain.

I=E2=80=99ve said it before, I=E2=80=99ll say it again. There=E2=80=99s =
nothing which is really any better about just having try_int() return =
TRUE on success rather than the converted value, and not having =
to_int().

But I=E2=80=99ve had this argument several times now, so I=E2=80=99m not =
going to have it again on the mailing list. This will be my last word on =
that suggestion.
--
Andrea Faulds
http://ajf.me/