Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75994
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain bof.de designates 80.242.145.70 as permitted sender)
To: internals@lists.php.net
Cc: Pierre Joye <pierre.php@gmail.com>, Andrea Faulds <ajf@ajf.me>
Date: Thu, 24 Jul 2014 10:33:24 +0200
Message-ID: <1914924.AS6fu4y4Km@rofl>
User-Agent: KMail/4.11.5 (Linux/3.11.10-17-desktop; KDE/4.11.5; x86_64; ; )
In-Reply-To: <CAEZPtU73tzcwS2vYU8awK_qqK1sVHiK8-qZzqywf-L0N6Q9Ybw@mail.gmail.com>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <CAEZPtU73tzcwS2vYU8awK_qqK1sVHiK8-qZzqywf-L0N6Q9Ybw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart82721445.KyFPpKM4hL"
Content-Transfer-Encoding: 7Bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: php@bof.de (Patrick Schaaf)

--nextPart82721445.KyFPpKM4hL
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

> The argument saying that it is not the PHP way is somehow incorrect
> here, given that we already do that for classe. The type jungling
> makes sense in implementations, as it always was but argument 
passing
> and validation have been a source of pain since very long. I could
> imagine one exception with the "numeric" type, which could accept
> anything and got converted to integer/numeric values, like "1235ab" or
> other weird things.

Personal opinion of a nonvoter, just for the record :)

The fact that roughly everybody in the strict-and-validation camp in the 
recent discussions, adds in a different view on "with the exception of", 
very very strongly suggests that the strict-and-validation POV is wrong 
wrong wrong.

On the one hand, because calling code will become sprinkled with 
casts on function calls to coerce the arguments to conform to the strict 
interpretation.

And on the other hand, because validation needs, for all practical 
purposes, are far more finegrained than any half-a-dozen-type scheme.

So, I'm 100% in the cast camp, i.e. interpret scalar type annotation of 
function arguments as syntactic sugar for explicit casts at the beginning 
of the function.

best regards
  Patrick

--nextPart82721445.KyFPpKM4hL--