Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80117
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54A78410.3050600@gmail.com>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me>
	<CAEZPtU79=VX1Scm6vVn-9iuHD=qqRoPMrsR4Ymqd9=QQeQbRCg@mail.gmail.com>
	<54A778AB.6020804@gmail.com>
	<CAEZPtU6PtfRvxykJup4L=n52WAevf2cZ6q5ZmCqYmiSTzO3Aqw@mail.gmail.com>
	<54A78410.3050600@gmail.com>
Date: Fri, 2 Jan 2015 22:04:18 -0800
Message-ID: <CAEZPtU5bUgH=K4u+6wqk2dc7HZb-qZw6+RFKs9Zd4DUYT-6nag@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: pierre.php@gmail.com (Pierre Joye)

On Fri, Jan 2, 2015 at 9:54 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi!
>
>> I am not sure about that. Parameters handling is one specific case,
>> userland parameter handling even more. It could be a good move to do
>
> Making internal and userland parameters work differently and having
> scalar type errors behave differently from object type errors by having
> one throw exceptions and another errors looks like a mistake to me. It
> only makes handling errors harder as you'd have to handle two types of
> situations instead of one.

I was not clear, sorry.

Parameter handling in general as described in this RFC are a special
case. This addition is somehow different from other arguments handling
we have, whether it is used for internal functions or userland. I only
see Exceptions even more useful in userland code.

There is no change per se to existing functions. Or to say it in a
better way, I am not keen to begin to chagne every 2nd internal
function to apply this new RFC, it could cause some bad headaches.
However, new functions and the likes, explicitally relying on this
RFC, may be a good candidate to have a different handling for bad
argument.

>> that as a 1st step, with this RFC.
>
> I don't think "1st step" is a good approach here. The language should
> provide consistent expectations, including about what happens when you
> pass certain data to it, including error conditions. If we have
> different types of error conditions between internal and userland
> functions, it would not be a good thing.

Agreed, but still. New userland codes could have huge benefits if we
allow that. But changing every internal function may have a bad
impact.

> We should make all parameter handling work the same way - so if you pass
> a parameter and it does not match the expectations, you know what you're
> getting. If it works one way to internals, another for user functions,
> it would only make it harder to handle.

Right again. Still not sure about the perfect solution without
impacting too much existing userland code.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org