Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31310
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.166.182 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:from:to:references:in-reply-to:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language:message-id;
        b=goIUtQ4AITDwD0pvzvk3tMJDvBfBSzSI+BWIUsj+5Y+ybvCuLAUB00NbQ8Ud/8e3EpXkZ9WUKBRf3Lh0NyS3t7TZyc5x9+2xaWYkSopCoLMuR+C7HxTi+8JGNpmNwSMVooYiqq5ocyd+3fHP0LYYy+1AtJscFyuBWEEoNQVpK8U=
To: "'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>
In-Reply-To: <E996AAF4A714DF4D9BD59E9418957A2128CF7D@peak8sbs.peak8solutions.local>
Date: Sat, 28 Jul 2007 20:00:52 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcfRdEVJWZN/giK5SmegsiCpXiykvwAAdNwAAAExLXA=
Content-Language: en-us
Message-ID: <46abe6c8.4f99220a.6e0c.2bb5@mx.google.com>
Subject: RE: [PHP-DEV] Re: Type-hinted return values in PHP5?
From: will.fitch@gmail.com ("Will Fitch")

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.

For example:


class Test {
	function blah(mysqli $db) {

	}
}

This validates at the language level the value passed is an instance of
mysqli.  That is much more handy than doing this each time:

class Test {
	function blah($db) {
		if ($db instanceof mysqli)
			.....
	}
} 

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
more towards what PHP was meant not to be.  Of course, that is part of
evolution and adaptation; adapting to user demands.

I think it would personally be nice if type-hinting was available for
functions/methods and not variables (at this point). 










-----Original Message-----
From: Jeremy Privett [mailto:jeremy@peak8solutions.com] 
Sent: Saturday, July 28, 2007 7:21 PM
To: Larry Garfield; internals@lists.php.net
Subject: RE: [PHP-DEV] Re: Type-hinted return values in PHP5?

And Zend Studio does this for you already, if you use comment your code
correctly. I really don't see a good use for this, either.

Jeremy

-----Original Message-----
From: Larry Garfield [mailto:larry@garfieldtech.com] 
Sent: Saturday, July 28, 2007 6:05 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5?

On Saturday 28 July 2007, Stanislav Malyshev wrote:
> > It would give you similar benefits to input type hinting, but
instead of
> > "Functions are now able to force parameters to be objects...", it
would
> > also read "Calling functions are now able to expect return types to
be
> > objects...". If a function was defined to return object Z, but
instead
> > returned false, then obviously there is something wrong and it could
be
> > caught before calling code sees it expecting it to be something
else.
>
> Catching language-level error in application code is usually harder
than
> just handling it in user code. And if you are talking about
distinction
> between false/null and actual object, language level is the wrong
level
> to catch such things.
> If you handle the error in runtime, you could have the check as well.
If
> you don't, the script breaks anyway, so it is not going to help you
much.
> Even more, the return value is the product of the module code, while
> input values are product of the outside code. So when you say "I'm
going
> to process only type X, and I make a requirement for others to pass
only
> X to me", it makes for me more sense than saying "I'm going to return
> only type X so I'm making restriction for myself to return only type
X".
> The latter is more like declaring variable types, which have its
> functions in compiled languages but usually is not happening in
dynamic
> interpreted languages.
> Also, since from the client side there's no way to check if the
function
> you are calling actually does have the return type restriction, it's
> quite hard to program basing on that from the client side. So you
> actually check it in one place (library) and use it in entirely
> different place (client) which is usually bad idea since the client
> becomes too reliant on internal details of the library.
>
> > If I, or someone else decided to make a patch for this, and assuming
it
> > worked exactly like I described, would it be accepted?
>
> I don't know... I personally don't see much use for it, but others may
> disagree.

I think the only serious advantage I could see would be to allow 
context-assistance IDEs more data, so they could provide
method-completion.  
As nice a feature as that would be, I don't think it's worth modifying
the 
language syntax for.  I agree that in a loosely typed language that sort
of 
thing needs to be checked by the application code anyway.

-- 
Larry Garfield			AIM: LOLG42
larry@garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an
idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the
possession 
of every one, and the receiver cannot dispossess himself of it."  --
Thomas 
Jefferson

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php