Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76004
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <33bf22776118d2b4ddafee7014a826b2@mail.gmail.com>
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>
	<33bf22776118d2b4ddafee7014a826b2@mail.gmail.com>
Date: Thu, 24 Jul 2014 12:38:50 +0200
Message-ID: <CAEZPtU6o2syeD_ebjmx7y8Crmi2JC80SyF6+NmRFrmVLvdU7+A@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.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: pierre.php@gmail.com (Pierre Joye)

On Thu, Jul 24, 2014 at 12:25 PM, Zeev Suraski <zeev@zend.com> wrote:

> We definitely do not..

Well, open list, if some like to discuss it, we can. But see below, it
may not be necessary.

> 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).

Just like we'd to add full OO concepts right with 5.0.

> 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.

Except for the cases I listed in my 2nd mail, which you certainly did
not read. However, my mistake, I had an outdated version of the RFC
and clearing my local cache shows me the actual one, which matches
100% what I would like to see and wrote in my replies in this thread.

> 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.

I do not like these errors either, I would prefer to have the same
than with class arguments, consistent, easy to catch for the
developers. So yes, maybe a 2nd question about how bad arguments
should be handled would be a good thing.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org