Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108809
MIME-Version: 1.0
References: <005101d5edae$7b7c3e10$7274ba30$@gmx.de> <CAF+90c8RmtGaa_KfptNMP0yQ6_xRWJ_z_zPj5JU45E2+qoE0Dw@mail.gmail.com>
In-Reply-To: <CAF+90c8RmtGaa_KfptNMP0yQ6_xRWJ_z_zPj5JU45E2+qoE0Dw@mail.gmail.com>
Date: Mon, 2 Mar 2020 14:55:53 +0000
Message-ID: <CALKiJKq4KN1F-mrCCOUBoz04zWju9PQbH_T9O2Rk0c--+hmL5g@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000eac4fe059fe0621c"
Subject: Re: [PHP-DEV] Re: [RFC] Userspace operator overloading
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000eac4fe059fe0621c
Content-Type: text/plain; charset="UTF-8"

On Mon, 2 Mar 2020 at 14:30, Nikita Popov <nikita.ppv@gmail.com> wrote:

>
> I think others have already expanded on why it's not possible to group
> operators in a meaningful way. The DateTime example is probably the most
> pertinent there, in that DateTime + DateTime is illegal, while DateTime -
> DateTime is legal. If we can't even require both + and - as part of one
> interface, there is very little we can require.
>


In my opinion, not being able to overload both + and - is a sign that the
class is "abusing" operator overloading, in that it is using it to build a
domain-specific language, rather than truly overloading *operations*.

An overload of "DateTime - DateTime" wouldn't represent "subtraction" for
precisely the reason that "DateTime + DateTime" doesn't make sense -
DateTime doesn't follow arithmetical logic. Instead, it would represent a
domain-specific definition of "difference". A more "correct" operator
overloading would be DateTime +  DateInterval, and its inverse DateTime -
DateInterval.

The common consensus seems to be that we don't want domain-specific
overloading (the example of << and >> in C++ has been mentioned several
times). If that's the case, then an interface that prevents you
implementing DateTime - DateTime seems perfectly legitimate.

Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000eac4fe059fe0621c--