Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77179
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.170 as permitted sender)
References: <6893A97A-EC4C-4124-B804-96E2A26B953F@ajf.me> <20140914000718.GB14312@phcomp.co.uk>
 <3177B936-50C1-4E5D-8687-FD235C72B411@ajf.me> <54153692.7050500@sugarcrm.com> <9CE963B0-E624-4267-BC2A-0F8D1F985DAE@ajf.me>
In-Reply-To: <9CE963B0-E624-4267-BC2A-0F8D1F985DAE@ajf.me>
MIME-Version: 1.0
Thread-Index: AQH5MaeemLSb1j8ep/xQjNgxWkCohgKCBGZJAZwOL3sB2X0+HwIihyKTm2z2S8A=
Date: Sun, 14 Sep 2014 15:17:32 +0300
Message-ID: <6f2236e18c61d30b247e1c6bb2de10f1@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>, Stas Malyshev <smalyshev@sugarcrm.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Sunday, September 14, 2014 3:08 PM
> To: Stas Malyshev
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
>
>
> The problem is that we *can't* be consistent. Internal functions already
live in
> this completely different world from user land functions. Nullability is
handled
> differently. They use implicit casts in places as if they were user land
functions
> with no parameter types at all. In other places they have strongly typed
> parameters. If they are passed invalid data, they usually just return
NULL and
> emit a warning, though this depends on the function. User land
functions, by
> contrast, will emit a recoverable error if the wrong type is passed. To
make
> these two consistent would require massive backwards-compatibility
breaks.

I honestly don't see why we can't be consistent for the simple types, or
at least strive to be as consistent as possible as opposed to introducing
a complete parallel universe for userland functions, that's inconsistent
with the entirety of the rest of PHP.  We don't have to be consistent with
ALL internal functions, which obviously have the option of doing custom
checks and return failures not only if you fail to, say, pass on a string
- but also if that string is not of a special format.  But then, you have
the option of doing that also in userland functions using custom code.
The question is not the customized cases - it's the standard behavioral
cases - comparing zpp rules for scalars and the newly-introduced rules for
userland scalars.

We could definitely strive to be consistent;  Introduce some changes to
the implicit casting rules for internal functions and implement the very
same rules for this brand new userland functions.  I'm definitely against
this RFC in its current form.

Zeev