Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89999
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
Message-ID: <1451936344.323.14.camel@kuechenschabe>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>, patriciotarantino@gmail.com
Date: Mon, 04 Jan 2016 20:39:04 +0100
In-Reply-To: <CAESVnVqoikwzKAnB13x-6pjoJnw3jCzAh1BdZpX=yE0ffpQfcg@mail.gmail.com>
References: 
	<CAESVnVqoikwzKAnB13x-6pjoJnw3jCzAh1BdZpX=yE0ffpQfcg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC Operator Overloading in Userspace
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Sat, 2016-01-02 at 18:14 -0800, Sara Golemon wrote:
> https://wiki.php.net/rfc/operator-overloading

Back in the days when I created the first implementation of operator
overloading in the engine[1] I didn't see it fit for the language.
Meanwhile we have more type hints and stuff making it a bit less magic.
I still don't think this approach is really good. for instance we loose
associativity; taking the Complex example:

   <?php
   $a = new Complex(1, 2);
   $b = 3;
   echo $a + $b; // works
   echo $b + $a; // will error out
   ?>

Of course this can easily be fixed by looking at the order, at least in
this simple case. In a more complex example where a function might
return an integer, double or complex number this becomes more
complicated.

For this to work we'd need non-member functions to do this and we need
function overloading ...

I believe  we'll only get a half-baked solution and I prefer the current
state over half-baked.

johannes

[1] http://news.php.net/php.internals/14558