Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75596
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender)
Message-ID: <53C6CFB7.8090908@sugarcrm.com>
Date: Wed, 16 Jul 2014 12:17:11 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>, Zeev Suraski <zeev@zend.com>
CC: Andrey Andreev <narf@devilix.net>, 
 Rowan Collins <rowan.collins@gmail.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me> <CAGAGxbZG+c46P4E2pmEHNnEv=4DyTrHOuXbZu3zAOSU3M6-A-A@mail.gmail.com> <05CE2216-C5D9-4937-9F2E-AA1407284D9F@ajf.me> <53C460DF.5040304@sugarcrm.com> <53C53A96.2040303@gmail.com> <53C55342.1010207@sugarcrm.com> <53C563B3.6060905@gmail.com> <CAPhkiZwvqW=d3Ayn-=Hx5HfkcOFB+gQ6rRoFThxA8hESK4WLrA@mail.gmail.com> <54536191-1B92-4933-973F-0C8289D13A4C@ajf.me> <00d12255efc53466245b21a83ff7d474@mail.gmail.com> <1CE2ACC0-D6CA-407B-99C7-4914311B733E@ajf.me>
In-Reply-To: <1CE2ACC0-D6CA-407B-99C7-4914311B733E@ajf.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> As has been pointed out already, that would be inconsistent with
> existing type hints. zend_parse_parameters emits E_WARNING and
> returns FAILURE, while type hints raise E_RECOVERABLE_ERROR. To make
> scalar type hints not emit E_RECOVERABLE_ERROR and instead do
> something weaker would introduce *more* inconsistency, not less.

That's why it is proposed to unify that and always produce E_CAST when
implicit cast makes an "iffy" decision. As for the mode of failure where
conversion can not be done - we can unify that too. The only reason why
internals produced E_WARNING and not E_ERROR was because we did not have
E_RECOVERABLE_ERROR but in general I see no problem with doing
E_RECOVERABLE_ERROR every time cast can not be made, if it's done in
PHP.next. Usually if you pass something unusable to the function, it's a
sign of serious breakage, and function can not really continue. I don't
see much problem with making it consistent E_RECOVERABLE_ERROR.

> Also, again, while these new rules aren’t quite the same as zpp’s,
> they are largely the same, and these rules are able to be summed up
> clearly in a single sentence, unlike the confusing and inconsistent
> zpp rules. We could fix zpp later, but that would be harder as it
> would break backwards-compatibility. And again, these new rules only
> different from zpp in very few places (integral values, “123abc” and
> booleans). -- Andrea Faulds http://ajf.me/

You say it as if it is an advantage. It is not. Having a rule that is
subtly different in 10% of places is actually worse than having one
totally different, because you start relying on it being the same, and
you don't change your tests to capture the elusive 10%, and everything
works just fine, and then you get in production scenario where data
happens to hit that 10% and your code goes bananas.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/