Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52067
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        b=aiqgynUeMEt+7/qu3RIVPtD1iPyrblDtYidUoOfVYltxd3Ptsj+1t9fkML3L1CGEJQ
         0iMR/T2J03SsMwUOPP+bLr/KOmhl5LWU0QawNOy7tCSS9zvdSsTqBqXVDebz4u2VJWfs
         szIzqqCNqn4fzbFE7NCfq38df192a4BqLX4F0=
MIME-Version: 1.0
Sender: tyra3l@gmail.com
In-Reply-To: <4DB9A7BE.6010307@sugarcrm.com>
References: <AANLkTimDdM4Udx53qW8jU4NuP3kU8+vmU6y4ZgXRVn+X@mail.gmail.com>
	<BANLkTinMW_iqqOPJCuLnCB+-VEKxapPdGg@mail.gmail.com>
	<4DB923E6.3020307@sugarcrm.com>
	<BANLkTi=4FzRJuYpK3C_ZD=JYZq2xq6hzJw@mail.gmail.com>
	<4DB9A7BE.6010307@sugarcrm.com>
Date: Thu, 28 Apr 2011 20:04:39 +0200
Message-ID: <BANLkTinB6rbzxWRJzyp1Nr+eLh8TO3tfFg@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Felipe Pena <felipensp@gmail.com>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf30363ac30fece004a1fe64c6
Subject: Re: [PHP-DEV] [RFC] Return type-hint
From: info@tyrael.hu (Ferenc Kovacs)

--20cf30363ac30fece004a1fe64c6
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 28, 2011 at 7:45 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
>
>  I see many advantages of the introduction of return type hinting.
>> - you can guarantee that your methods returns only what is explicitly
>> stated (or else it blows up, the same as for arguments)
>>
>
> You can't, because function resolution happens in runtime, so the only
> point you know what the function called "foo" returns is the moment where
> you're already calling it, not a moment before.
>
>
it's the same as for the current argument type hinting.
you can access that information via Reflection
http://hu2.php.net/manual/en/reflectionparameter.getclass.php


>
>  - it can save you from having to define the return type in phpdoc, your
>> code can define it's behavior
>>
>
> Why I need being "saved" from documenting my code properly? Anyway, the
> function code defines the behavior, declaration of return type just ensures
> function would fail in runtime if your code tries to return unexpected data
> - but how is it helpful? The client of this function doesn't even know that
> before actually calling it!


why did we added ppp if people can define in the documentation(or in the
method name :/) that which method is public and which isn't


>
>
>  - I think maybe the language itself could use that information, for
>> performance, etc. improvements (we know that the return value will be
>>
>
> That would need static compile-time binding of functions, which implies
> static binding of includes, etc. - basically, compiling PHP code as a whole
> in one monolitic application.


I see


>
>
>  created runtime, but we can throw it away if it doesn't match the return
>> type or something), maybe we can use that information to throw errors on
>> compile time if we find a non runtime decided return value which doesn't
>> match with the return type.
>>
>
> Sorry, what is "non runtime decided return value"? And how is "compile
> time" different from "runtime" in your opinion - when exactly that "compile
> time" happens?
>
>
Just throwing ideas around.
when we parse the php code to opcode, the interpreter could use the typehint
information to catch trivial cases(eg. we cannot tell that return $foo is
valid, but we can tell that return FALSE is not valid if the typehint
doesn't specify that).
I hope this clears that up.

Tyrael

--20cf30363ac30fece004a1fe64c6--