Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52083
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain phcomp.co.uk designates 80.68.91.63 as permitted sender)
Date: Fri, 29 Apr 2011 09:55:33 +0100
To: internals <internals@lists.php.net>
Message-ID: <20110429085533.GF8496@phcomp.co.uk>
Mail-Followup-To: internals <internals@lists.php.net>
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> <20110428181630.GA8496@phcomp.co.uk> <4DBA46FD.5090106@sugarcrm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4DBA46FD.5090106@sugarcrm.com>
User-Agent: Mutt/1.4.2.2i
Organization: Parliament Hill Computers Ltd
Subject: Re: [PHP-DEV] [RFC] Return type-hint
From: addw@phcomp.co.uk (Alain Williams)

On Thu, Apr 28, 2011 at 10:05:01PM -0700, Stas Malyshev wrote:
> Hi!
> 
> >I will accept that sometimes it must always be done run time, eg:
> >
> >     $funcName($arg)
> >
> >but that still allows most calls at compile time.
> 
> This is not the issue. This is the issue: $foo->bar($arg).
> There's no way to resolve it in "compile time", whatever that means, 
> without having a type on $foo.

Which a good compiler with time to burn (think HipHop not Zend) could do, eg:

	function joe(SomeClass $foo)

or:

	$foo = new SomeClass();

or:

	function SomeClass fred() { ... }
	...
	$foo = fred();

> >Anyway - the check for return type would be done in the called function,
> >not the calling function.
> 
> That's the point. You don't get any extra safety on the caller's side, 
> because you don't actually know much about the called function. With 

You could by resolving the 'requires' at compile time, most of which you
can. Yes you can find some examples when it won't, but don't ignore
the most for the sake of a few.

> You are talking about pretty big change in language nature - introducing 
> strict typing. "It's just option, don't use it if you don't want" 
> doesn't really sound good in this case. If it's in the language, it 
> should make sense and sit well with the rest of the language.

And it will.
Objects are a big thing in the language - but their use is not mandated,
many programs don't use them.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>