Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89970
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.53 as permitted sender)
To: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>,
 patriciotarantino@gmail.com
References: <CAESVnVqoikwzKAnB13x-6pjoJnw3jCzAh1BdZpX=yE0ffpQfcg@mail.gmail.com>
Message-ID: <56888E9A.5020400@gmail.com>
Date: Sat, 2 Jan 2016 18:59:38 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <CAESVnVqoikwzKAnB13x-6pjoJnw3jCzAh1BdZpX=yE0ffpQfcg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC Operator Overloading in Userspace
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Patricio Tarantino has asked me to help him propose Operator
> Overloading in PHP 7.1 (based in part on my operator extension in
> PECL).  I think we can expose this to usespace as magic methods with
> very little overhead (the runtime check and dispatch is already there,
> after all).

We could, but I'm not sure whether we should. One of the reasons why
userspace operator overloading was kept out was that a lot of its uses
make code worse, not better. When you see expression that looks like
addition but you know it can do literally anything, that makes reading
the code so much more frustrating. I mean, you can *hope* * still means
"multiply", but you can't know it anymore. And there are not that many
types for which * has natural meaning.

Additionally, introducing about 9000^W^W a lot of new magics drastically
raises both cognitive complexity of the language (now we have 14 magics,
adding operators (and RFC lists only arithmetic ones, though one may say
why stop there - C++ certainly didn't) more than triples that count.
Also, implementing them in consistent fashion would be non-trivial, and
imagine what fun would be had when +, += and ++ work differently (btw,
why have different implementations for + and += at all?). And then we
get questions of commutativity and associativity...
What I'm trying to say, doing proper operators set is not that trivial,
and besides a very small set of use cases, I'm concerned it would be
used to write very clever write-once read-never code instead of good code.

-- 
Stas Malyshev
smalyshev@gmail.com