Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57032
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 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
In-Reply-To: <4EF38DBA.2030808@sugarcrm.com>
Date: Thu, 22 Dec 2011 15:14:28 -0500
Cc: Anthony Ferrara <ircmaxell@gmail.com>,
 Dmitri Snytkine <dsnytkine@ultralogistics.com>,
 Sebastian Bergmann <sebastian@php.net>,
 "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <5BCF1CA0-6E0D-41B0-8EAC-4EFE9325B08A@gmail.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> <CAAyV7nEsGVEGMFmuYqotJaoL7vnW2p-sr+O_sLuG8r323T3k+A@mail.gmail.com> <4EF38DBA.2030808@sugarcrm.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
From: will.fitch@gmail.com (Will Fitch)


On Dec 22, 2011, at 3:06 PM, Stas Malyshev wrote:

> Hi!
>=20
>> 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
>=20
> I'm sorry but I don't see how what you describe is good. You stopped =
worrying about checking inside the function, but unless you have started =
checking outside the function you've just made your code less robust =
that it was before. While in the case of strict class typing the case of =
mismatched classes is so rare that occasional failure is easily =
identifiable, you didn't really improve your code. I agree that it makes =
you type less - but the cost of it is your application also does less - =
you don't have a capability of gracefully handling a problem any longer. =
Again, with object strict typing, this might be OK since failures are =
very rare and usually a result of obvious mistakes caught early in =
testing - but if they are not, you didn't really gain much.

I wouldn't be opposed to moving from raising an E_RECOVERABLE_ERROR to =
some type of exception.  In fact, I'd support it (in a discussion over =
that RFC).  Your argument of not checkout outside the function is =
exactly why many are against type hinting scalars to begin with.  A =
generic "scalar" keyword being added would help some, but only protect =
against objects, resources and arrays.

> --=20
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20