Did a test implementation only supporting a few types (int, float, bool, string).

This works as expected.

Test code:
----------
class test {
	public function __cast($type) {
		switch($type) {
			case 'string': return 'a string';
			case 'bool': return true;
			case 'float': return 123.456;
			case 'int': return 978;
			default:
				var_dump($type);
				return null;
		}
	}
}

$t = new test();

var_dump((string)$t);
var_dump((int)$t);
var_dump((float)$t);
var_dump((bool)$t);

Result:
string(8) "a string"
int(978)
float(123.456)
bool(true)

Here's the patch file for this simple implementation against PHP 5.3.0alpha2.

http://ookoo.org/svn/snip/php-5.3.0alpha2_class_cast_func.patch

This is awesome

Backported to PHP 5.2.6 :

http://ookoo.org/svn/snip/php-5.2.6_class_cast_func.patch

AWESOME!
php developers, please, we need it!!
http://bugs.php.net/bug.php?id=46404

Please test the following extension :

http://ookoo.org/svn/snip/phpcastable/

This extension adds a "Castable" interface. Any class implementing this interface have to implement a __cast() function. This function will be called when the object needs to be casted to a type.

This extension is EXPERIMENTAL and needs more testing/review before being used in any production system.

This is such a nice Implementation and very useful, but i prefer to add the methods __toBool, __toInt and __toArray rather than __cast, stay tuned with PHP's other magic methods..

I dont agree fully with that post in feature request #38508 from helly. If that'll be the way, why did the decision for magic methods?
Isnt that all complex although? ^^
We know, but in my eyes (and many others), i think that these magically stuff is one of the top key features for php. And none of these features will become critism i think. If not needed, just dont use them!

The additional goody __toInvoke() introduced in 5_3 is a such nice addition for developing "quick gets" based on nested object sets:
<?php
$magazine(3)->getArticles();
// old way
$magazine->getArticle($magazine->useMagazine(3));
?>
This helper is a "backdoor" like way to enable PHP to fully write nested Objects like in Javascript. And my opinion for that: I LIKE THIS :)

I think this is a very very discussable topic to the changes for 5_3 or 6_0 beside the wanted support for traditional type hinting and utf8!

thanks

I wonder why you guys do not implement in core the PECL php_operator which would make code style and life much easier.

I cannot imagine a Number class which needs (int)$obj for every single operation.
Please do not get me wrong, __cast is a good idea, but it covers only explicit cases while every other decent language (C#, Java, Python) allows developer to implement implic cast behavior as well.

This, in PHP 5.3, would be excellent (but probaly an illusion thou).
Regards

This would be very useful in order to be able to define a specific evaluation method for an object as a boolean, to, for example, simplify if-switches, so you can just do:

if ($obj)
{
	//...
}

Here an example of a class which toggles its own value each time it's evaluated as a boolean:

class ToggleObj
{
	var $val = FALSE;

	function __toBool()
	{
		$ret = $this->val;
		$this->val = !$ret;
		return $ret;
	}
}

$obj = new ToggleObj;

if ($obj)
{
	//Does not enter
}

if ($obj)
{
	//Now it does
}


Or going further, to make even table rows highlighted:

foreach ($rows as $row)
{
?>
	<tr class="<?=$obj?"":"highlighted"?>">
		<td><?=$row?></td>
	</tr>
<?php
}

Thanks.

NeoEGM
http://www.neoegm.com/

WHEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEN?!!
There was 3 years to patch sources!

I think we all need this badly. It just suits the direction in which the 5.4 is going.

Regarding same functionality I think it is worth nothing that the conversion to boolean should be implicit. Otherwise such code could not work:

<?php
function check($response) {
  if ( ! $response ) die('error');
}

$resp = new Response();
check($resp->isSuccessful());
check($resp); // this would fail without the cast if the conversion was explicit
?>

My suggestion is to replace `__cast($to)` with `__toObject($object)` (or even 
`__toSelf($object)`). That way, we have a magic method for each type to cast to, 
and we avoid the messy switch/if statements.

While __toXxx() may more in line with the existing __toString() IMHO __cast() is more in line with the other magic functions and gettype(). If I could choose I'd take __cast() and deprectate __toString().

I think we're preaching to the choir at this point. I don't think its a high 
priority to anyone who is actually developing PHP. If we want this feature, then 
we should take it upon ourselves to implement and we should all support it 
getting 
in to a release version.

I'm sure once this is in there then that is when the masses will wonder how they 
ever did without it.

> If we want this feature, then we should take it upon ourselves
> to implement and we should all support it getting in to a
> release version.

Well said, see <https://wiki.php.net/rfc/howto>.