Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79055
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.223.178 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <CAFMT4NodhUcS3f-nnCpxGuR=AA6-g9wTchzeS7faTeu9SSL5xw@mail.gmail.com>
References: <D7C8CEF6-625E-4489-8EFC-8FCAA16302D2@ajf.me> <CAFMT4NodhUcS3f-nnCpxGuR=AA6-g9wTchzeS7faTeu9SSL5xw@mail.gmail.com>
Date: Thu, 20 Nov 2014 16:45:52 -0800
Message-ID: <CADajX4Ctcn7HHu_YbxunT1TALbx8Koe1F4pOO_YwjKv5n8=Vgg@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: Andrea Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions
From: aharvey@php.net (Adam Harvey)

My -1 is pretty much the same as Levi's:

On 19 November 2014 13:57, Levi Morrison <levim@php.net> wrote:
>   - 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.

I'm also somewhat concerned that these functions are conflating two
concerns (validation and conversion).

>   - 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.

+1: the idea of adding two sets of identical functions except for how
they signal errors isn't one I like.

Derick raised a good point elsethread: this is really tied into how we
want to signal errors in PHP 7. If we switch to exceptions, then let's
figure out a plan of attack and switch to exceptions everywhere, not
just in the odd function here and there. If we don't, then the to_*
functions shouldn't be added.

> To summarize: I like the idea of having tools that helps us convert
> between types in a lossless way, but I don't think this proposal is
> what is best for PHP. -1 for me but I hope to see this revisited.

I don't know that I'd ever be a strong +1 on this (adding more type
conversion matrices to PHP doesn't seem like a good idea to me,
whether it's in the language itself or in the standard library, and I
feel like we have the validation part of this already in filter and
ctype), but if we figured out the error handling situation and had
only one set of functions, I could probably grit my teeth and abstain,
at least.

Adam