Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108817
Return-Path: <rowan.collins@gmail.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 32709 invoked from network); 3 Mar 2020 11:34:03 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 3 Mar 2020 11:34:03 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id 13A391804D8
	for <internals@lists.php.net>; Tue,  3 Mar 2020 01:53:08 -0800 (PST)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net
X-Spam-Level: 
X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,
	MALFORMED_FREEMAIL,MISSING_HEADERS,RCVD_IN_DNSWL_NONE,
	RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no
	autolearn_force=no version=3.4.2
X-Spam-ASN: AS15169 209.85.128.0/17
X-Spam-Virus: No
X-Envelope-From: <rowan.collins@gmail.com>
Received: from mail-il1-f194.google.com (mail-il1-f194.google.com [209.85.166.194])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(No client certificate requested)
	by php-smtp4.php.net (Postfix) with ESMTPS
	for <internals@lists.php.net>; Tue,  3 Mar 2020 01:53:07 -0800 (PST)
Received: by mail-il1-f194.google.com with SMTP id p8so2176461iln.12
        for <internals@lists.php.net>; Tue, 03 Mar 2020 01:53:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:cc;
        bh=fY/ESqewJIkE4B+thyqboEDN03NHfU4jNM+ygtCEZUc=;
        b=jgv5/QCYZnTSmWqE/vtqDBNRznQzBHjElOQGmXHHU3nSemKNvaaudVSKO+P+fXM+F4
         k9hMYziRD8jEW4hSsHzExiaBRmZGyHcxzPUm+xlWSFhzyW2/65m74z81jQm9+JriMmBV
         ttLxJg/m44EwvAi2KGNPvTLI0pvFG8hTbLAebsUDMyRJAH8SFg6VNZMmRwQY58shYZx4
         6VTdrdPMSZBfCSclroBKSpT0dDepEp5I/3tIaayFRZ3ZOCql5k5m9b4HYR2x+gb2cuh7
         0+n1+Cg4QfDD33hBA03a0Fyso9Cow0xwvchM4yHXustrLEw0T27mz+9ONMlhNxgnlaz5
         51eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:cc;
        bh=fY/ESqewJIkE4B+thyqboEDN03NHfU4jNM+ygtCEZUc=;
        b=ZW2OE+oavyypI4sulj1hhNTM2M5pp77+h+nkW38uawjQs7NdZgXp2xMAH+qC4vDKsk
         KVg2mdcyH5qI92ta/IavgRLit0fkop8NLaVvtzFQiMmU/O3o7dBiOyT6Qtm89Y5IQSbi
         dR2p8R0VpdK/mzym8H6Z75QqtowADYiLpDK17DZzCy7s17NA5Zv2YnGHGLLfzWOLRzbl
         xO2UQyYNcPF0lgqcMT+8jCIc2c4gcUtwD0cJPn2b4nRd7YvBo3cPp2XLCGUywg2sE0ff
         1bPVi1OpnlTmw2UiECIs7RD82Mnnhswmh+2hb+Q68ZKyt4xj4HaWqb7fibIUErsoGIdH
         bEuQ==
X-Gm-Message-State: ANhLgQ3heitv2f6HZPAjn/dClxhfNxhQPuFER1QpufneCm7u2uB+DW5l
	nqXrZuNAZm1sEQSFVtcsQFemSOBWH4XSBLDZqY69tfZc
X-Google-Smtp-Source: ADFU+vs64RQgR85cCvJqPLE0V7huFDAN70ktGCbR4GGKKga34ZySJQ0qvWHWmz1/Wv0kus7cMYpjutc70olRZB1kb5A=
X-Received: by 2002:a92:aac1:: with SMTP id p62mr3811909ill.120.1583229183797;
 Tue, 03 Mar 2020 01:53:03 -0800 (PST)
MIME-Version: 1.0
References: <005101d5edae$7b7c3e10$7274ba30$@gmx.de> <479ea7da1e5738d7bed6c8dd773c@news.php.net>
In-Reply-To: <479ea7da1e5738d7bed6c8dd773c@news.php.net>
Date: Tue, 3 Mar 2020 09:52:52 +0000
Message-ID: <CALKiJKpe_uejb9v=kCHQ_kKWJAXHJPwFaXTbf5Du_Nwp5kTkOA@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000192d85059ff0458d"
Subject: Re: [PHP-DEV] Re: [RFC] Userspace operator overloading
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000192d85059ff0458d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Terje,

I think both of your examples are compatible with the idea of grouped
operators, as long as we don't constrain a type to implement all operators
with the same right-hand side.


On Mon, 2 Mar 2020 at 17:23, Terje Sletteb=C3=B8 <
terje.slettebo@sandefjordbredband.net> wrote:

>
> Adding and subtracting money makes sense, but it makes no sense to
> multiply
> or divide them, and this is just *one* domain.
>


This is true, but it does make sense to multiply and divide them by
numbers, for instance $totalPrice =3D $unitPrice * $quantity

In general, if $a + $a represents addition, then $a * 2 should logically
give the same result. As has been raised, there is an argument for keeping
/ separate, for types that cannot handle fractional operations; it would be
a matter of choice whether $price / 2 should be supported because it would
lead to fractional pennies/cents.



> $total_discount =3D $total * $discount;
>
> Here, $total_discount and $total is Money, while $discount is a
> Percentage,
> so we should be able to define a method that allows you to multiply Money
> with Percentage, and return a Money object. Adding Money and Percentage
> would
> make no sense, but multiplying them does.
>


If this operator was implemented in isolation, it would again be drifting
into domain-specific language territory. (I don't personally have a problem
with that, but many people vocally object to it.)

However, it could easily be made part of a consistent set of arithmetic
operators:

On class Money:

Money + Money =3D> Money
Money - Money =3D> Money
Money * int =3D> Money
Money / int =3D> Money
int * Money =3D> Money
int / Money =3D> Error
Money * Percentage =3D> Money
Money / Percentage =3D> Money
Percentage * Money =3D> Money
Percentage / Money =3D> Error

Optionally, on class Percentage:

Percentage + Percentage =3D> Percentage
Percentage - Percentage =3D> Percentage
Percentage* int =3D> Percentage
Percentage / int =3D> Percentage



Regards,
--=20
Rowan Tommins
[IMSoP]

--000000000000192d85059ff0458d--