Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31313
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.166.179 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:from:to:cc:references:in-reply-to:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language:message-id;
        b=RyFn1hypjfIgf0eDIHoiQ0KsFZfrPywZeiAWY8YGc1B3dqL4VbizTbeDZcmw8au7DG/SvdYNCzKRiSYg8q4zvNruJGXcAddxEEcjrup3yn9Rg+VXzsLlniJu5IdqIaSpY69c1UihyrptWaGPlB8n+F+3jTEe40NqmBFP/bc9Ato=
To: "'Stanislav Malyshev'" <stas@zend.com>
Cc: "'Jeremy Privett'" <jeremy@peak8solutions.com>,
	"'Larry Garfield'" <larry@garfieldtech.com>,
	<internals@lists.php.net>
References: <74.B1.05050.EADEC964@pb1.pair.com> <08.07.20814.2587AA64@pb1.pair.com> <46ABD596.3060005@zend.com> <200707281905.27822.larry@garfieldtech.com> <E996AAF4A714DF4D9BD59E9418957A2128CF7D@peak8sbs.peak8solutions.local> <46abe6c8.4f99220a.6e0c.2bb5@mx.google.com> <46AC4A9B.9070704@zend.com>
In-Reply-To: <46AC4A9B.9070704@zend.com>
Date: Sun, 29 Jul 2007 10:42:25 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcfRt3B/rXl3iMAjQYmd0oPPPXfSbwAPN1lg
Content-Language: en-us
Message-ID: <46acb569.0661220a.3591.ffffb051@mx.google.com>
Subject: RE: [PHP-DEV] Re: Type-hinted return values in PHP5?
From: will.fitch@gmail.com ("Will Fitch")

I see your point, but maybe I didn't explain myself well enough.

Take the example of an interface.  Interfaces aren't directly accessible
(callable), they don't have any functional code in them.  So why have them?
What is the single best advantage of an interface, especially in a very
large organization?  It ensures consistency.  

Take PDO for instance.  They are a perfect candidate for interfaces.  The
actual implementation of the close() method will differ based on the RDBMS,
but functionally, to the end-developer, they are the same.  It closes the
database connection.  Once a class implements an interface, and the
end-developer knows this, they don't have to worry about the name of the
method that closes the connection.  Also, if the lead architect decides that
there must be a method called foo() in each of the given libs, he/she needs
only to enforce this through the interface, which is implemented by each
class!  This can also assist in debugging.

I understand that there's a real difference between type-hinting return
values and parameters, but reverting back to the interface practice, why not
depend on the developer to add a new form of documentation to "promise" to
implement certain methods?  

Will


-----Original Message-----
From: Stanislav Malyshev [mailto:stas@zend.com] 
Sent: Sunday, July 29, 2007 3:07 AM
To: Will Fitch
Cc: 'Jeremy Privett'; 'Larry Garfield'; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5?

> On one hand I agree, since PHP is so loosely typed.  But it's hard to make
> the argument that type-hinting return values is pointless, since PHP
allows
> (class) type-hinting with parameter values.  I personally think
type-hinting
> is very nice, and not for the purposes of IDEs.

The difference is that typehinting works this way:
1. I'm a library, I want to get type X for $foo
2. I put typehint, so I didn't need to check if $foo is X
3. If you pass not X to $foo, my code is going to tell you that you 
can't do that

And return type works like that:
1. I'm a library writer that says foo() returns X
2. I have to use for it, since I don't use foo()
3. You're client, so you read the docs and see foo() returns X
4. You write code which supposes foo() always returns X
5. I decide these return types are more trouble than they are worth, and 
make foo() return false on error, removing return type.
6. Your code has no way to check I did that, so it's broken now.

Basically, it sums up to documentation - if documentation isn't right 
(or if it changed and you didn't follow) your code is going to break and 
you have no way to prevent it. That's what you have now with @return - 
why add language construct?

> If one of the best selling points of PHP is its typeless environment, then
> why make any of these available?  It appears that we are moving more and

If it was up to me, I'd probably not bother adding input typehints 
either :) But as I said above, input typehints are significantly 
different from return types.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com