php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #50969 operator overloading for classes
Submitted: 2010-02-08 22:49 UTC Modified: 2010-02-12 18:23 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: sylvain at abstraction dot fr Assigned:
Status: Not a bug Package: Feature/Change Request
PHP Version: 5.3.2RC1 OS: all
Private report: No CVE-ID: None
 [2010-02-08 22:49 UTC] sylvain at abstraction dot fr
Description:
------------
I would like to know what is the current PHP team position about operator overloading in PHP for classes.

Operator overloading has been stated Bogus in http://bugs.php.net/bug.php?id=9331 but it was more than two years ago.

I think it would be nice to have a discussion about that topic. If you recently had one I would be interested if you could indicate me where I can find it.

Best Regards.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-02-08 22:59 UTC] johannes@php.net
Operator overloading in a dynamically weak typed language is bad as reading code gives no information what's happening. If you really want it go to http://pecl.php.net/operator maybe that still works.
 [2010-02-08 23:15 UTC] sylvain at abstraction dot fr
I'm not particularly aware of operator overloading in other language but I don't see why it would be less readable in PHP than in any other language as the only way to know what is happening is to read the code of the method overloading the operator.

Anyhow, do I have to take as official PHP Team position that you won't implement it ?
 [2010-02-08 23:54 UTC] johannes@php.net
Well it is implemented, as you can see when following the link, I myself once created a patch to make it a bit nicer in syntax but it will never be implemented (as far as never goes)

And well the issue, in the most simple form, is something like this:

function foo() {
    return bar() + baz();
}

In today's world during are view you can say "this will return a numeric value"with operator overloading you can say "this will return something or maybe fail"

Becomes especially "funny" with

return bar() + 4;

Sure there's convention and comments and things but that won't help and you can always do

   return bar()->add(baz());

or

   return someclass::add(bar(), baz());

which makes the intention clear. Yes $a + $b + $c + $d might be bit nicer to read than the long form - but only as long as you know what types you have ...
 [2010-02-12 13:28 UTC] sylvain at abstraction dot fr
Well it is maybe implemented but it's beta and has not been updated 
for over 3 years. It is not usable in a 
production environment.

Regarding your point that it is not readable, objects implementing 
Iterator can be used with the foreach 
statement (which is an overloading) and for objects with multiples 
propertiesn you don't know what is done 
unless you read the code.

So, I don't see why we could not have overator overloading already 
having foreach overloading.

Things can get "funny" with overloading, yes, but that's not a reason 
to not implement it. You can't state you 
won't allow something because some people will not use it correctly, 
in that case, you allow nothing and you 
don't implement a dynamically weak typed language. It is up to the 
developer to secure its implementation. You 
must have a little faith in him.

Here an exemple of what I have in mind based on the Iterator model :

interface OperatorOverloading
{
	public function __add($object);
	public function __substract($object);
	public function __multiply($object);
	public function __divide($object);
	public function __increment();
	public function __decrement();
}

class foo implements OperatorOverloading
{
	private $anynumber = 0;

	public function __add($object)
	{
		if (!$object instanceof __CLASS__)
		{
			throw new Exception('Come on !!!');
		}
	
		$return = new foo();
		$return->anynumber = $this->anynumber + $object-
>anynumber;

		return $return;
	}
	
	public function __increment()
	{
		$this->anynumber++;
	}
	
	public function __decrement()
	{
		$this->anynumber--;
	}
	
	public function __substract($object)
	{
		throw new Exception('not implemented');
	}
	
	public function __divide($object)
	{
		throw new Exception('not implemented');
	}
	
	public function __multiply($object)
	{
		throw new Exception('not implemented');
	}
}

Regards.
 [2010-02-12 16:45 UTC] rasmus@php.net
Sorry, this will never happen.  Basic operators need to be 
deterministic in PHP.  You can disagree if you like, but that isn't 
going to change anything.
 [2010-02-12 18:23 UTC] sylvain at abstraction dot fr
I don't disagree, I was just asking for good reasons to not implement it and "it's not readable" or "it could get funny" are not according to me.

Regards.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 21:01:27 2024 UTC