Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75421
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.182 as permitted sender)
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <CAF+90c-ojALBgeyXu+f2tW6LoW8+4XGVpu_+i9SyX=u4RSoxug@mail.gmail.com>
 <027E65EF-C4FC-474C-92BB-D99EFADDEEED@ajf.me> <ada4093ad61814c182f8ca31939962ea@mail.gmail.com>
 <BDC11A4E-0610-49A3-B8AE-E9D3627B75C8@ajf.me> <eab1ceea2084415d21736a69c4ac6fdc@mail.gmail.com>
 <53C29EE4.3090808@gmail.com> <63e5b1c38d6e0c5111987e78d9b59be3@mail.gmail.com>
 <E2926DD2-B0AE-4A87-BEA8-F07FE49CE4B5@ajf.me>
In-Reply-To: <E2926DD2-B0AE-4A87-BEA8-F07FE49CE4B5@ajf.me>
MIME-Version: 1.0
Thread-Index: AQJuUFVOlGiX172RfpkkW7aXwqSXwwOWY2SKAql1dl4CVdDzGgKRSJF6AWT2/k4CFsPBuAJBAJoIAfHW5ZKZyhL0MA==
Date: Sun, 13 Jul 2014 18:45:49 +0300
Message-ID: <b3026b451453e3c2412bbf45c59f5003@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Jocelyn Fournier <jocelyn.fournier@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Sunday, July 13, 2014 6:19 PM
> To: Zeev Suraski
> Cc: Jocelyn Fournier; PHP internals
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
> 1. Casting type hints
> 2. Strict type hints
> 3. Scalar type hinting with casts
>
> (There are others, but I won't talk about them)
>
> I'm not of the opinion that the first option, where we just cast and
never
> error, is ideal. It does ensure the values are of the correct type when
they get
> to you, so it keeps PHP's type juggling, but it is unlikely to catch
bugs where
> the wrong value has been passed.

Let's stop for a moment right here.
If we emit notices, or even new E_CAST, do we not get the exact same
ability to catch errors you'd get from E_RECOVERABLE_ERROR?
Even reading Nikita's piece, he's saying he dislikes that option for
'obvious reasons', but I see nothing obviously wrong with this approach.
In fact, it gives you the full power of ensuring the correct types in the
'inner code', allows you to catch 'bad conversions' if you wish to (many
don't, but I agree some and perhaps many would), and allows you to use
this feature in the most widespread way possible while minimizing the
amount of code you need to write in order to use it (no inflation in
necessary try/catch blocks).  Unlike what's suggested in that piece, it's
not equivalent at all to docblocks, as it is in fact enforced, and as you
said, has the benefit of being able to write the 'inner code' without
worrying about the input types.

 Whether we go for option #1 or #3 doesn't change the amount of bugs you
can find *if you wish to, unless I'm missing something.  Option #3 forces
you to explicitly deal with 'error' situations (which may or may not be
errors), while option #1 leaves it up  to the developer whether he wants
to write 'E_CAST clean' code or not, similarly to E_STRICT (assuming we
introduce E_CAST, we can choose an existing error level too).

Zeev