Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67883
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuRC8WfrR26W+1hVgXDMt28OQXek68w=9YEGs2ueEiOewg@mail.gmail.com>
References: <CAA9esyS0YL=biVS37ix-yBea7RmZXPnhVk_xKjfz6x+gfN5LNw@mail.gmail.com>
 <CAL+t6cF9JTr9e=A15LvhfgN0DaV8_k4SuEDxQ408fNAAx=8Z_A@mail.gmail.com>
 <CAOX1NOfBPTggj6-WA=ArXjw1UvhUbVC=+FjCYvk6Bgp856biFg@mail.gmail.com>
 <CACwt+Je1vS7MkqShM8+FaDJmAoyaTDCWtTSOuOwG4iWUnyvKHA@mail.gmail.com> <CAMUwpuRC8WfrR26W+1hVgXDMt28OQXek68w=9YEGs2ueEiOewg@mail.gmail.com>
Date: Wed, 26 Jun 2013 17:23:58 +0200
Message-ID: <CAA9esyTayGSsPG3je354z394sr=6Hq40ZkYWcu27bmVk=vO_pg@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Patrick ALLAERT <patrickallaert@php.net>, Maxwell <Max@maxvandervelde.com>, 
	Sherif Ramadan <theanomaly.is@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Request for comments - new PHP feature: return typing
From: florinpatan@gmail.com (Florin Patan)

On Wed, Jun 26, 2013 at 3:35 PM, Julien Pauli <jpauli@php.net> wrote:
> On Wed, Jun 26, 2013 at 2:58 PM, Patrick ALLAERT <patrickallaert@php.net>
> wrote:
>>
>> 2013/6/26 Maxwell <Max@maxvandervelde.com>:
>> > Sherif,
>> > I have to disagree with you on this in the same way that we have type
>> > hints
>> > for input variables on methods, this could also be useful.
>> > Consider an interface with a getter method defined. As it stands now in
>> > php, they're not entirely useful, since you can't define what type of
>> > object your expecting from the implementer. That greatly reduces the
>> > functionality of an interface and this proposal gives solution to that
>> > problem.
>> >
>> > Florin,
>> > I think the overall concept is good, I want to see something like this
>> > in
>> > the future, but I think this might be the wrong approach. I don't think
>> > we
>> > should be hinting primitives. if we're going to have a return type hint
>> > on
>> > a method, I would have it match the functionality of the input type
>> > hints
>> > for functions we already have, where you can hint at an instance of an
>> > object type, such as Iterator or StdClass, or an array, but not hint
>> > primitives such as int and string, like I currently see in the draft.
>> > Also, you should be aware that your proposed syntax for the return type
>> > (
>> > <type> ) is interfering with:
>> > https://wiki.php.net/rfc/protocol_type_hintingand seems unnecessary to
>> > me.
>>
>> Thanks Maxwell, you summarized very well what I was thinking about it.
>> So +1 from me for the general feature at a first glance, but it should
>> then be very close to what is possible with input type hinting.
>>
>> It makes it possible to write interfaces that acts like specifications
>> and to easier the writing of:
>>
>> class Foo {
>>     public function bar($input) {
>>         $return = Baz::foo($input);
>>         if (!$return instanceof ReturnType)
>>             trigger_error("Cannot divide by zero", E_USER_ERROR); //
>> or throwing some RuntimeException
>>
>>         return $return;
>>     }
>> }
>>
>> to:
>>
>> class Foo {
>>     public function <ReturnType> bar($input) {
>>         return Baz::foo($input);
>>     }
>> }
>
>
> +1 for the global idea as this would help so much OO programs and framework
> based programs.
>
> But what Sherif said proves as well the limits of the idea. PHP is not
> strongly typed. So each check, should it be type hinting or return type
> hinting, has to be done at runtime , which is bad for performances.
>
> Not talking about the type juggling which could lead the programmer as
> shooting himself.
>
> Julien.Pauli

Hi,

Type juggling is explicitly not allowed in the draft and I would hope
it can remain the same in the final implementation.
That's actually one of the things I want to prevent.
I love PHP because of type juggling which can be very handy at times
but for such feature this would be a total no no.

As for limited applicability, I think that frameworks could benefit
greatly from this as well as systems where you really count on having
the least surprise possible from code. And as more people turn to PHP
to bootstrap their startup, idea or whatnot, having more code quality
features would only help the language to maintain its traction and
improve the life all-around.


Best regards
----
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan