Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115772
To: Jordan LeDoux <jordan.ledoux@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAMrTa2EO-5nyoCYkHhMVxQ4nucRoHJj0=M=W22kUaW0jpHkHLg@mail.gmail.com>
Message-ID: <9aa7874a-a09b-4412-d98b-7c97b3d4439d@processus.org>
Date: Mon, 23 Aug 2021 13:46:54 +0200
MIME-Version: 1.0
In-Reply-To: <CAMrTa2EO-5nyoCYkHhMVxQ4nucRoHJj0=M=W22kUaW0jpHkHLg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------6A19689FE59595E4D95A25E5"
Content-Language: en-US
Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads
From: pierre-php@processus.org (Pierre)

--------------6A19689FE59595E4D95A25E5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Le 06/08/2021 à 18:34, Jordan LeDoux a écrit :
> Hey all,
>
> ...
>
Hello,

I'm sorry I couldn't answer the last few weeks I was on vacation.

I just wanted to say, I'm opposed to user-land operator overloading for 
a few reasons:

  * it may produce shorter, simpler code, but it hides the real logic
    behind,
  * not all mathematical arithmetic operators have a semantic meaning
    for let's say, collections: it's not evident to me that "/" means
    partition (even thought the "+" for union is trivial),
  * they are hundreds different operations on collections which have a
    common taxonomy in many languages, there will never be enough
    operators for all, we will end up with Frankenstein API's where
    there will be operators for some operations, and methods for others,
  * methods in plain english (or whatever is your language) are always
    more readable in the end,
  * you can CTRL+click to navigate (in a decent IDE) on a method call,
    not on an operator,
  * step-debugging will be a bumpy ride,
  * some people will use them good, many will misuse them, some will do
    evil with those,
  * and hell, if "->" doesn't mean "access that object member" anymore,
    but "hey, the implementor could do anything at all instead", sky
    will fall upon us.

I'm not sure the benefice-risk ratio is good enough.

That said, in the other side, I'm +1 with equals(), compareTo() and 
those kind of magic methods for the "==" and comparison functions, this 
is something that PHP lacks, but I'm unsure this worth making all 
operators user-land overridable.

I'm always favorable to something that makes the code being semantically 
and non-ambiguous to read, and in my opinion userland operators create 
more mess than they solve, they basically encourage people to make 
non-readable stupid shortcuts in their code.

Best regards,

Pierre


--------------6A19689FE59595E4D95A25E5--