Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40880
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.46.31 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type;
        b=sArEKAHdhCfa7KNy+ogWaRX6dZZURZY2Ip6DI9xEsdhs4570j4XBCxbPnRuK9W0Dj/
         5vkQxDH7RVHBHP5+DRun+24MZJTtSae/y/SK3e/Hcnn8oaXg4CAk3v8OIWzUWZULRRnA
         g8aOdXX8b5i9yF3AHmYKO42SkMRa35ySAngIQ=
Message-ID: <fa64dc0a0810071305u23571474nd0075f7f85a509c9@mail.gmail.com>
Date: Tue, 7 Oct 2008 15:05:20 -0500
To: internals@lists.php.net
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_55562_7483551.1223409920564"
Subject: Type hinting return values
From: shawnmc@gmail.com ("Shawn McCool")

------=_Part_55562_7483551.1223409920564
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,



I've submitted this suggestion once before, but it was quickly shunned with
two generic answers: "It's not the PHP way" and "It all boils down to
documentation.  That's what PHPDoc is for."  Both of those are partially
correct, but I feel the benefits and other uses certainly make a better
case.



While type hinting return values from class methods is not the current PHP
way, neither were abstracts, interfaces, namespaces or even
object-orientation if you go back far enough.  PHP is constantly evolving,
and that evolution derives from other languages, programming techniques and
innovation (which PHP certainly contributes to).  Obviously this scenario is
standard in other languages and are typically absent from the scripting
type.



Adding type hinting for parameters was huge and this functionality will
compliment it.  For those who are worried about generic (mixed) return
values and backwards compatibility, we could allow the keyword "function" to
remain in place and represent a generic return type.  While there are
concerns of performance with this additional hit on the Zend Engine, I still
feel it's worth exploring.



Although documentation is inherently created, it is not the purpose of type
hinting return values.  Devs working in multi-developer environments,
library authors and others directly benefit from this.  There are no
surprises when the return value of a method call is declared a reference of
"SomeClass".  If the class author attempts to return "OtherClass", the
error, E_ERROR in this case, would be thrown in the method that declared
that return type, making debugging and ultimately responsibility easier to
identify.  What value does prefixing a class method with the keyword
"function" provide?  I understand that PHP's evolution is the result of
this, but if we allowed the substitution with a class name, scalar or
compound type, no harm would be done.



I feel it's reasonable to reopen the conversation of this subject for the
purpose of justifying adding the functionality or doing nothing at all.  We
seen the need for parameter type hinting, which eliminates the need for
logical checks, and implemented it. What disadvantages are there for doing
the same with method return values?

------=_Part_55562_7483551.1223409920564--