Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44898
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain phcomp.co.uk designates 213.152.38.186 as permitted sender)
Date: Fri, 10 Jul 2009 12:05:22 +0100
To: "Ionut G. Stan" <ionut.g.stan@gmail.com>
Cc: internals@lists.php.net
Message-ID: <20090710110522.GD19636@mint.phcomp.co.uk>
References: <7.0.1.0.2.20090708224156.0ac5a438@zend.com> <af54caaf0907090139q23a5574fscdcf29321c7f8f0e@mail.gmail.com> <312025EF-84D0-4411-A0A7-4F0379C3105F@pooteeweet.org> <af54caaf0907090932w2e5921e6l55f854ff80020dc8@mail.gmail.com> <22CAD497EA2F476DAECEF9302D0B087A@pc> <98b8086f0907091150r47e7a103jaa50fcf7d5b32186@mail.gmail.com> <4A568B33.9000501@gmail.com> <98b8086f0907091744w7ab598dckc427d0a9484664b2@mail.gmail.com> <20090710102302.GC20283@gerbil.thgnet.it> <4A571981.80900@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A571981.80900@gmail.com>
User-Agent: Mutt/1.4.2.2i
Organization: Parliament Hill Computers Ltd
Subject: Re: [PHP-DEV] Type hinting - Request for Discussion
From: addw@phcomp.co.uk (Alain Williams)

On Fri, Jul 10, 2009 at 01:35:45PM +0300, Ionut G. Stan wrote:
> On 7/10/2009 13:23, Giovanni Giacobbi wrote:
> >On Fri, Jul 10, 2009 at 02:44:52AM +0200, troels knak-nielsen wrote:
> >[...]
> >   
> >>For example, instead of:
> >>
> >>     function addFive(int $x) {
> >>       return $x + 5;
> >>     }
> >>
> >>You would simply do:
> >>
> >>     function addFive(is_numeric $x) {
> >>       return $x + 5;
> >>     }
> >>
> >>Since $x is guaranteed to be numeric, it is safe to to arithmetic on
> >>it. No reason to explicitly type cast here.
> >>
> >>     
> I like it too. Not only it solves the initial problem, but it also 
> allows userland extensions. For example,
> the current patch does not provide checks for callables, but we already 
> have is_callable in the core.

Hmmm, but it makes simple cases more complicated and slower. But I do like the
idea of generalising it with a function to handle 'strange' cases.

So, we have 3 syntaxes:

1)	function Foo(int $x) {

  $x is tested to be integer, if it isn't an error is raised - either by exception
  or just a fatal error.

  A problem with this is that it could yeild some surprising results, eg:

	Foo(4/2);		-- OK
	Foo(4/3);		-- FAIL since 4/3 yeilds a float

  In this last case people would learn to:

	Foo((int)(4/3));


2)	function Foo((int) $x) {

  $x is cast to int, ie converted iff possible - otherwise an error is raised:
	int -> int -- OK
	float -> int -- OK if in the range for integer
	string -> int -- OK iff it is 100% clean:
		'10' - OK
		'10.1' - OK as string -> float -> int
		'10ten' - FAIL/ERROR
	etc

   What happens when someone tries to use this syntax where he is casting to an object ?
   I suggest that this fails unless the object has a __cast method, in which case that is invoked:

	function Foo((MyObject) $x) {
		...
	}

	class MyObject {
		function __cast($x) {
			if( ..... )
				return new Foo('abcd', $x);
			....
		}
		...
	}


3)	function Foo(is_int($x)) {

  Function is_int is called, an error is raised if it returns false.

-- 
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
Past chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h>