Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84158
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 74.125.82.180 as permitted sender)
References: <d238d736f8fcde9e649cb38c9b05fcc1@mail.gmail.com>
 <DUB113-W139512BB87516EAD168575DF9130@phx.gbl> <ed4e3cf6c363aa74cdd44c7d908f5d3a@mail.gmail.com>
 <54F42DDF.2070505@lsces.co.uk>
In-Reply-To: <54F42DDF.2070505@lsces.co.uk>
MIME-Version: 1.0
Thread-Index: AQHbEgvqZ08kgCvmYfG4mXODzCFejgD7DxroAZSg+X8CNOWwVZzNUHPw
Date: Mon, 2 Mar 2015 11:47:33 +0200
Message-ID: <bce398d196ee18f1b8c33870a1a84e68@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Lester Caine [mailto:lester@lsces.co.uk]
> Sent: Monday, March 02, 2015 11:31 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated
> RFC
>
> Andrea's post highlights the fact that we did try a fix when PHP5 came
> out.
> What it fails to add is perhaps why the change was reverted? Still today
> there
> are people pressuring to have it restored? As this thread has shown. At
> the
> end of the day, this fine tuning of casting action has very little to do
> with the
> type hinting debate? Now IS the time to discuss the rules but not as part
> of
> some other RFC? It deserves it's own independent discussion as it SHOULD
> apply what ever happens over type hinting.

The whole discussion is presently limited to the area of type hints, and
this is unlikely to change for 7.0.  I think it's good to think about post
7.0 changes - perhaps bringing the rule-set to other areas of PHP (namely
implicit casting), but no, it's not the time to seriously discuss this IMHO.

> Thomas's example in my book is where a number of things come into play?
> My first thought would be just where is this actually processed and so
> where
> is it trimmed? Additionally how about '001'? However it does highlight
> that a
> single 'int' hint is not going to satisfy everybody anyway? The thing
> perhaps
> to point out here is that we are looking in this case at a source that may
> well
> be using unicode and wonder if THAT may not be more of a problem here?

Whether we have weak, strict, coercive or yellow-red type hints added to
PHP, they're absolutely not supposed to satisfy everyone.  They're supposed
to satisfy most use cases, but not all - for the remaining X percent, you'd
have to write a bit of custom code, which is fine (either do away with the
hint and do custom validation, or use the hint - but do a bit of
preprocessing in the calling code).  It's not as if everything we deal with
in scalars is going to fit into the various scalar type hint buckets anyway.
Functions that accept URLs, or emails, or other types of
scalar-but-specifically-formatted data have to be validated with custom code
anyway.  It's fine for other cases to require a bit of custom validation -
as long as the key use cases are covered.

I'm obviously biased but I believe that the coercive rules actually cover a
lot more ground than the weak+strict sets.  In other words, with
weak+strict, overall, you're going to have to add custom code in a lot more
cases than with the coercive rule set (either because weak is too weak and
strict will very frequently be too strict, while coercive provides a
rule-set that accepts sensible values and reject non-sensible ones, making
it work out of the box in most cases).  But even with coercive, it's
definitely not a one size fits all solution, and it's not supposed to be
either.  You still have custom code available to you.

Zeev