Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57029
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EF38573.6060305@sugarcrm.com>
References: <2095305E-D4E3-4D7E-8218-32EE99688E0C@GMAIL.COM>
	<CAF+90c-Wtok1fnVxokYUFQhbYnMcNDwWWT63F8NDp+JnxCDMew@mail.gmail.com>
	<2C90FB94-38C4-4270-8C6A-B89304BA8ED8@gmail.com>
	<CAEZPtU6gneOOehrsz-qVifmNxg6tnyLt9hqfnAwKZmfpXdeC9Q@mail.gmail.com>
	<159A7CA2-8561-40DA-9434-CAAE12304DDB@gmail.com>
	<005701ccc0b3$58c8dee0$0a5a9ca0$@alliantinternet.com>
	<CALtuQzD5EuZ+a66-P4opfd7CyijKkxBLOrBkvn1xnMXoB0cLxw@mail.gmail.com>
	<20111222145159.GY25857@alliantinternet.com>
	<006101ccc0ba$46b81160$d4283420$@alliantinternet.com>
	<CAF=va1Vv_T3RVBhTbvJv+mCqOTpEx3LN1NtFk8PumwjHHPZWxw@mail.gmail.com>
	<4EF379D8.9000206@lerdorf.com>
	<4EF37C29.1010206@php.net>
	<4EF37D19.8080207@alliantinternet.com>
	<007e01ccc0dc$985f1cd0$c91d5670$@alliantinternet.com>
	<4EF38297.5040507@alliantinternet.com>
	<008001ccc0df$3c8faa70$b5aeff50$@alliantinternet.com>
	<4EF38573.6060305@sugarcrm.com>
Date: Thu, 22 Dec 2011 14:58:51 -0500
Message-ID: <CAAyV7nEsGVEGMFmuYqotJaoL7vnW2p-sr+O_sLuG8r323T3k+A@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Dmitri Snytkine <dsnytkine@ultralogistics.com>, Sebastian Bergmann <sebastian@php.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
From: ircmaxell@gmail.com (Anthony Ferrara)

Stas,

> it's not a solution for the problem it is presented to be - it does> not make your code more robust or fail less or saves you effort on> development
I'm going to have to disagree with you there.  Type hinting DOES save
me a LOT of effort in development.  I can stop worrying about checking
to make sure the parameter that I got is what I want it to be, and
just use it.  The runtime will check and enforce that for me.  When
using things like Dependency Injection, it's crucial to have
type-hints, otherwise you need to do the enforcement yourself (which a
lot of people don't do).

Sure, it does introduce its own issues with throwing exceptions (I
convert all ~notice errors into exceptions by default), but at least I
know **why** the error happened.  If the parameter is not correct, it
will tell me what was passed vs what was required.  Without type
hinting, I would be in a situation where I would be responsible for
that error (if I validated), or a weird error about an undefined
method call (if not validated).  Either way requires more work for
regular code writing...

> While the case of wrong object type is rare enough to warrant application
> failure in case it happens - the case for scalar types is completely
> different. It was discussed many times on the list.

I half disagree here.  I disagree in the thought that the rarity
should dictate the check.  In fact, I would argue the exact opposite.
That the more often an event happens, the more pressure there should
be to fix it as it would fix more really odd bugs...  In this case, I
agree with you that I think strict scalar hinting would not actually
solve the problem.  But that doesn't mean a solution shouldn't be
found.  I really like Rasmus's concept of "casting hints", where it
would try to cast to an int and error only if it couldn't.  Now, this
surely would be very difficult to do in practice, and very hard to
handle all the edge cases (especially when dealing with references,
that could be HUGE).

Anthony

On Thu, Dec 22, 2011 at 2:30 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>
>> What I mean is that you can catch recoverable fatal error in your error
>> handler and at least be notified of what happened. Yes, you cannot go back
>> in your script to corrent anything after that but you can show a detailed
>> error message and send error email to developer.
>>
>> Just the same thing you can do when you hint class name for your input
>> parameter - it will generate catchable fatal error if object is not an
>> instance of expected class.
>
>
> Exactly, strict typing has same flaws everywhere, and this is exactly the
> reason it's not a solution for the problem it is presented to be - it does
> not make your code more robust or fail less or saves you effort on
> development - it just produces different error messages.
> While the case of wrong object type is rare enough to warrant application
> failure in case it happens - the case for scalar types is completely
> different. It was discussed many times on the list.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>