Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58867
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL0xaBGL9ReS=zEo74rARrRRW7Fhjdg27Ni5ghzs8vpHoaP1eA@mail.gmail.com>
References: <CAAyV7nHOwCoci6W7-cvFEJi27Wz7qA-_0a6_qHVyzwkC6rjWQQ@mail.gmail.com>
	<CAMyk_AY-vYp_VbctGomyKN0fra0QU3E=rRmacazrRDWeZNgHPg@mail.gmail.com>
	<CAAyV7nHZohu1rkuLFdzAdD_JX3jgVJcfkxbdc6ZnuUCSvEGnJA@mail.gmail.com>
	<CAMyk_AZuhgmsb8ONpW3kYV7FgwBr4csGs+xoDrEt=c=c-PtvEA@mail.gmail.com>
	<CAJWj5+E8KSXzugb6xz+xm26WMPNxdoSaS14cZ8vpxYF2GCT7qw@mail.gmail.com>
	<CAMyk_AaOKOD1=Fxj=4iY56P7gCxb410hg_x9dER8qiTjnpvUTA@mail.gmail.com>
	<C379A30D-3B12-4C2B-B3A0-0B4D1B92BC44@gmail.com>
	<CAAyV7nF9GDAN4f92+XkKjLAGnZ4KukFOt0uMf2=hyA38M0YS2A@mail.gmail.com>
	<CAL0xaBGL9ReS=zEo74rARrRRW7Fhjdg27Ni5ghzs8vpHoaP1eA@mail.gmail.com>
Date: Mon, 12 Mar 2012 07:28:00 -0400
Message-ID: <CAAyV7nH7g3x7PcQr49GPLQH0jVdbqpYornBjPcnrKd3VSEayzQ@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: Tjerk Meesters <tjerk.meesters@gmail.com>, Lazare Inepologlou <linepogl@gmail.com>, 
	Simon Schick <simonsimcity@googlemail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
From: ircmaxell@gmail.com (Anthony Ferrara)

Arvids,

On Mon, Mar 12, 2012 at 4:39 AM, Arvids Godjuks
<arvids.godjuks@gmail.com> wrote:
> I should point out that returning false on param parsing failure on the
> language level is one thing (not to mention it's not ok to do that in the
> first place by my taste), but forcing that behavior on the user-land leve=
l
> is kind'a too much.

To be clear, that's not what I had meant at all.  I was talking about
ZPP returning false internally, not what the internal functions
themselves do (it's up to them to ignore the error, to go on, or raise
a different error).

> Consider how the code will become much more complicated - now you have to
> not only to check what you pass to the functions, but you have to check w=
hat
> it returns every single time (do I have to mention that false can be neve=
r
> returned by the function at all except when the param parsing fails?).

I agree 100%.  There's also a semantic difference between an error
state from the function and an error state from parameter parsing.
Which is why an E_RECOVERABLE_ERROR is my preferred state, since it
communicates the information properly...

> What is consistent and exists on the internal language layer
> not=A0necessarily=A0good for the user-land. I'm kind'a surprised no one t=
hought
> of that.
> As I said I can live with the throwing notices and warnings (and not
> E_RECOVERABLE_ERROR as I personally wanted), but returning false even not
> trying to run the function is just a bad idea all over the place.

I'm confused.  Do you not want E_RECOVERABLE_ERROR for parameter
failures?  Or do you, but could live with lesser as well?  I didn't
quite get that part...

Anthony