Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57048
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
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> <4EF3B56A.4040809@gmail.com>
 <-2451498990672032588@unknownmsgid> <4EF3BD21.2040301@sugarcrm.com>
 <-6952580475866195972@unknownmsgid> <4EF3C7F7.9010404@sugarcrm.com>
In-Reply-To: <4EF3C7F7.9010404@sugarcrm.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 22 Dec 2011 19:39:55 -0500
Message-ID: <4841689055873111589@unknownmsgid>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: =?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?= <keisial@gmail.com>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
From: will.fitch@gmail.com (Will Fitch)

Sent from my iPhone

On Dec 22, 2011, at 7:14 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> Hi!
>
>> Are you suggesting not allowing null to be returned, or provide an
>> indicator within the syntax that it may return null?  PHP would be the
>> first language I'm aware of that would do so in either case.
>
> No I am not suggesting that. I'm just pointing out the problems with the =
concept of strict typing in PHP and this particular instance of it. One of =
them is that many functions do not actually return one type but multiple ty=
pes depending on the result. It is a very common pattern.

And in those cases, they would continue to use the keyword "function"
and be considered unknown as they are today.

>
> BTW, which languages you are talking about? PHP peers - Python, Ruby, Per=
l, Javascript (to some measure), etc. don't have typing as far as I know. C=
omparing PHP to statically compiled strictly typed languages does not seem =
very useful to me. So could you clarify what do you mean?

Not seem useful? Then during the discussions of parameter type
hinting, which language did you compare it to? What about abstracts
and interfaces?

I don't compare PHP to ruby, python or JavaScript. Do I suggest
features that I find useful in other languages like C# or Java or even
in any of the ones you listed? Absolutely.

Limiting yourself to comparing features only found in interpreted
languages is a very narrowed scope. Yes, return type validation does
add overhead, just as parameters do (arguably more). But it is a
feature that is very valuable to many. Those who wish not to use it
can continue to do so.

Don't forget that while return checks are runtime, interface
definition and implementations are compile time.

>
>> The point isn't to restrict a type hint to always be returned. The
>> goal is to guarantee that if a value is returned, it will be of type
>> X. In the event it is inappropriate to return the value back, would
>
> All functions in PHP return values, so it is not possible that no value w=
ould be returned (yes, if you don't return anything it actually will return=
 null). So ensuring something is an object of type X prevents you from retu=
rning anything else, false/null included. If you make exceptions for null, =
then why not for false? If for false, then why not for true? Etc.

Because null is a standard already set by parameter type hints. I do
not want to sway away from that as it works well.  It is common for
null values to be considered "nothing", which is exactly what will be
returned if the specified hint isn't. All or nothing.

> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227