Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76003
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.179 as permitted sender)
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me>	<CAEZPtU73tzcwS2vYU8awK_qqK1sVHiK8-qZzqywf-L0N6Q9Ybw@mail.gmail.com>
	<12448510.rPWIJSKt4t@rofl> <CAEZPtU5U9Z75t3zToBTgWiyx3NKLUoEvxoz-RpVE2e6LFh54Ag@mail.gmail.com>
 <53D0CBE2.5010200@sugarcrm.com>
In-Reply-To: <53D0CBE2.5010200@sugarcrm.com>
MIME-Version: 1.0
Thread-Index: AQJuUFVOlGiX172RfpkkW7aXwqSXwwFk+rVEAfkAhK4B0r0g6QJWNVT+mjV3E9A=
Date: Thu, 24 Jul 2014 13:25:42 +0300
Message-ID: <33bf22776118d2b4ddafee7014a826b2@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: 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: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
> Sent: Thursday, July 24, 2014 12:04 PM
> To: Pierre Joye
> Cc: PHP internals
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
> That's called strict typing and was discussed many times. Do we really
> want
> another round of repeating the same arguments?

We definitely do not..

To elaborate, the notion that we already have strict class types for
classes, so we should have the same thing for scalar makes no sense at all.
Here's why:

1. If it was the case, we'd add this right when we added class type hints
(strict class types).
2. The fact of the matter is that we did not.  Why not?  Because scalars in
PHP behave in an inherently different way.
3. As I stated already, 'Dynamic Typing defines PHP, class type hints do
not'.  Class type hints were added at a *MUCH* later stage, as a part of the
major rollout of the new object model of PHP 5.  It was actually agreed that
the *only* way we'd add such type hints is if we weren't going to have them
for scalar types.

What we have on the table right now - casting type hints - can be made to
behave in a way that's consistent with the dynamic typing nature of PHP.

My main concern about the RFC the way it stands right now is that the
current direction involves E_RECOVERABLE_ERROR instead of E_STRICT or E_CAST
for data loss.  This results in both consistency issues with casting as well
as incompatibility with the dynamic nature of PHP scalars.  I know the RFC
author (Andrea) disagrees with me about it, but I think we need to find a
way to put this into a much wider decision.  Probably the most practical
thing to do is to put it as a secondary question in the RFC, although those
can be tricky.

Zeev