Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31308
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 216.148.227.153 cause and error)
To: internals@lists.php.net
Date: Sat, 28 Jul 2007 19:05:27 -0500
User-Agent: KMail/1.9.6
References: <74.B1.05050.EADEC964@pb1.pair.com> <08.07.20814.2587AA64@pb1.pair.com> <46ABD596.3060005@zend.com>
In-Reply-To: <46ABD596.3060005@zend.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200707281905.27822.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5?
From: larry@garfieldtech.com (Larry Garfield)

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