Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125614 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 67B451A00BD for ; Wed, 18 Sep 2024 02:48:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1726627861; bh=sdyg4a0Ih9NsaOJN/vEdTgga1YoIvxoSYcF+2UpiD2A=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BaFTYSUyuvApWcqiLFEPLykyp19lzgEwHxmsi2iwN6M3xXGDLAlHURYy2GPgSfEok TSNqKU4z8edkA6nKci9xuG8Lo40jxWzT067wb+sBfMwzJ3Fjy5xmSInshOCJzObq8R BQgNvCdLV4xtu7d4+6/ANpPMb3GdK4YVSkfr+/zGQwinX7xmXt+10va8ikR/fv1GXa eun6zgdWSQqXY54NgNamJgyGPy0dSlHwtx45PL+QGkstQ6NnhqdnHOAEgSGegirCjr o10GKa2f8RzF4uHvpwl8fzviDlk0eBB9ZF7JuVeVFphkWhYnMftlkIoGxNOHxlmxRR tO0c87lCMMxPQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8FAB7180061 for ; Wed, 18 Sep 2024 02:51:00 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 18 Sep 2024 02:51:00 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-2d8a54f1250so4317952a91.0 for ; Tue, 17 Sep 2024 19:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726627734; x=1727232534; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9X1c3rdQS/Cl7nS4B66pvE+Fx2pdEHdHgYKBttCal3w=; b=P1K8AsbpL6YMjQf3bwckcIN1rhsDpNo417QHwh5+OpbO7aTJmNKPIpzLVymzLLDnNe c9FVonR+a495juvfm1v7e6bJawTL8qmZhGJMlks1n+D86VDP8CV0w3i7BM0rq3tc7GU6 eO906+OPNTxXbWDxW4zN+Nbrl9IGhtMTlSIDzUSI5srnoSgK/dIfve7ZnERR0bFa5vN9 pKAjASxoVNqkifxtuPwwM5/ZcaditpcCzSMH+AdxpwIVVgUWzfGX2lCdfwGHH2Ac+UAH s2dzVrG+TdxY25H8tXLvkgmqIQuW1HzDXT6VsZCDClnApeYhaFXqpnO5AvkvVjwuwTXR jFag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726627734; x=1727232534; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9X1c3rdQS/Cl7nS4B66pvE+Fx2pdEHdHgYKBttCal3w=; b=WlIYXALTOisVdCwEfjrIkgHdcuQOsfQ3X0VWqEmJDI+Q3BNYRxyp90aeSdnnCoECT4 swonFlA2jnvJfrM8Y+UIx4geLFoLYyzojqan/Z0vaCdrj8JjgeefSFWKeKD+mlsXxV+c J4LjPq3iBhks7PPXn/qKr4Q5EFYGsWNOvFvYA7GIibGnNTcPzsDsy6sjCD5hruhJ19AZ rSgs3d6UJ2qfai18XzUDVT2A1GWOY/vHTgOHPZESE/VhX88tXu9Lcfp3UtcFYqlIuvSR hKUxoyX8yoylw9GIdGuxAoVA3DlDFcpky2XoYd0Bk77DvrVwxH9sfut3h74fysaw4TCC S9TA== X-Gm-Message-State: AOJu0YxXiEcL7dweJZtxboSHlsHrsXnqvwCekIi0j/dNLZbZrxITXR6i 7l3hgDUAHS7WUdapj0wISvnujuOEYAVsLwVa8EGflXVBD48Ky0n/jSRIUQnHnLlqpdLlsfzdR1i Q8YR0fU9p1BZY8mlvMz0zEwCE7H74+A== X-Google-Smtp-Source: AGHT+IFYGLtZ2rMqDvJ4hPF6CGJnyUrKb/ozJlRhV2sGR9jtjlZl3o/znlL4LtsSyaj57tklswEQl5f9gY87ncj0EXo= X-Received: by 2002:a17:90b:3616:b0:2cc:ef14:89e3 with SMTP id 98e67ed59e1d1-2db9ffcab27mr21929054a91.15.1726627733427; Tue, 17 Sep 2024 19:48:53 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <2551c06a-ec1f-4870-a590-aeb5752fc944@rwec.co.uk> <0f0444eb-8fc5-4c56-8528-5aa528988e73@rwec.co.uk> <782bc7c2-f179-4a79-a651-b1979e594d08@app.fastmail.com> In-Reply-To: <782bc7c2-f179-4a79-a651-b1979e594d08@app.fastmail.com> Date: Tue, 17 Sep 2024 19:48:40 -0700 Message-ID: Subject: Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again) To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="000000000000b5e00406225bd883" From: jordan.ledoux@gmail.com (Jordan LeDoux) --000000000000b5e00406225bd883 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 17, 2024 at 6:49=E2=80=AFPM Larry Garfield wrote: > On Tue, Sep 17, 2024, at 3:14 PM, Jordan LeDoux wrote: > > >> I think it's absolutely possible - and desirable - to choose a > philosophical position on that spectrum, and use it to drive design > decisions. The choice of "__add" vs "operator+" is one such decision. > >> > > > > Ah, I see. I suppose I never really entertained an idea like this > > because in my mind it can't even handle non-trivial math, let alone the > > sorts of things that people might want to use overloads for. Once you > > get past arithmetic with real numbers into almost any other kind of > > math, which operators are meaningful, and what they mean exactly, > > begins to depend a lot on context. This is why I felt like even if we > > were limiting the use cases to math projects, things like commutativity > > should not necessarily be enforced. > > > > The line `$a + $b` and `$b + $a` are SUPPOSED to give different results > > for certain types of math objects, for instance. The line `$a - $b` and > > `$b - $a` more obviously give different results to most people, because > > subtraction is not commutative even for real numbers. > > > > My personal opinion is that the RFC should not assume the overloads are > > used in a particular domain (like real number arithmetic), and thus > > should not attempt to enforce these kinds of behaviors. But, opinions > > like this are actually what I was hoping to receive from this thread. > > This could be the way forward that voters are more interested in, even > > if it wouldn't be my own first preference as it will be highly limiting > > to the applicable domains. > > I'm not sure where exactly in this thread to put this, so I'm putting it > here... > > Rowan makes an interesting point regarding operators vs operations. In > particular, the way the <=3D> logic is defined, it is defining an operati= on: > comparison. Using it for anything other than ordering comparison is simp= ly > not viable, nor useful. It's defining a custom implementation if a > specific pre-existing action. > > For all the other operators, the logic seems to be defined for an > operator, the behavior of which is "whatever makes sense in your use case= , > idk." That is, to use Rowan's distinction, a philosophically different > approach. Not a bad one, necessarily. In fact, I think it's a very good > one. > > But, as they are different, perhaps that suggests that comparison should > instead not be implemented as an operator overload per se, but as a named > magic method. The existing logic for it is, I think, fine, but it's a fa= ir > criticism that you're not defining "what happens for a method-ish named > <=3D>", you're defining "how do objects compare." So I think it would ma= ke > sense to replace the <=3D> override with a `__compare(mixed $other): int`= , > which any class could implement to opt-in to ordering comparisons, and th= us > work with <, >, =3D=3D, <=3D>, etc. (And, importantly, still keep the "s= pecify > the type(s) you want to be able to compare against" logic, already define= d.) > > A similar argument could probably be made for =3D=3D, though I've not ful= ly > thought through if I agree or not. Again, I think the previously defined > logic is fine. It would be just changing the spelling from `operator > =3D=3D(mixed $other): bool` to `public function __equals(mixed $other): b= ool`. > But that again better communicates that it is a core language behavior th= at > is being overridden, rather than an arbitrarily defined > symbol-function-thing with domain-specific meaning. > > There was an RFC for a Comparable interface back in the stone age (2010), > but it looks like it never went to a vote: > https://wiki.php.net/rfc/comparable > > Arguably, this would then make more sense as a stand-alone RFC that > happens to reuse a lot of the existing code and logic defined for operato= r > overloads, which are all still just as valid. > > That does not apply to the arithmetic, bitwise, or logic operators. > Overriding + or / for a specific domain is not the same, as you're not > hooking into engine behavior the way <=3D> or =3D=3D are. For those, I'd= prefer > to stick to the current/previous implementation, with the `operator` > keyword, for reasons I explained before. > > Jordan, does that distinction make sense to you? > > --Larry Garfield > Yes, I certainly understand the distinction. The RFC does not treat all operators equally. For many of them, the only opinion it holds is whether or not the operator is unary or binary, which is something enforced by the compiler anyway. But for comparisons, the RFC went out of its way to ensure that the overloads cannot repurpose any comparisons for non-comparison, non-ordering tasks usefully (as far as return value goes). In that sense, yes, I see how that feels more like an operation instead of an operator. The only hesitation I would have about that is the clunky/ugly feeling I get of having some of them be symbols and some of them be names for a reason that will be totally inscrutable to 95% of developers and just be "one of those PHP quirks". In principle though, I do get what you're saying here. Jordan --000000000000b5e00406225bd883 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Sep 17, 2024 at 6:49=E2=80=AF= PM Larry Garfield <larry@garfi= eldtech.com> wrote:
On Tue, Sep 17, 2024, at 3:14 PM, Jordan LeDoux wrote:

>> I think it's absolutely possible - and desirable - to choose a= philosophical position on that spectrum, and use it to drive design decisi= ons. The choice of "__add" vs "operator+" is one such d= ecision.
>>
>
> Ah, I see. I suppose I never really entertained an idea like this
> because in my mind it can't even handle non-trivial math, let alon= e the
> sorts of things that people might want to use overloads for. Once you =
> get past arithmetic with real numbers into almost any other kind of > math, which operators are meaningful, and what they mean exactly,
> begins to depend a lot on context. This is why I felt like even if we =
> were limiting the use cases to math projects, things like commutativit= y
> should not necessarily be enforced.
>
> The line `$a + $b` and `$b + $a` are SUPPOSED to give different result= s
> for certain types of math objects, for instance. The line `$a - $b` an= d
> `$b - $a` more obviously give different results to most people, becaus= e
> subtraction is not commutative even for real numbers.
>
> My personal opinion is that the RFC should not assume the overloads ar= e
> used in a particular domain (like real number arithmetic), and thus > should not attempt to enforce these kinds of behaviors. But, opinions =
> like this are actually what I was hoping to receive from this thread. =
> This could be the way forward that voters are more interested in, even=
> if it wouldn't be my own first preference as it will be highly lim= iting
> to the applicable domains.

I'm not sure where exactly in this thread to put this, so I'm putti= ng it here...

Rowan makes an interesting point regarding operators vs operations.=C2=A0 I= n particular, the way the <=3D> logic is defined, it is defining an o= peration: comparison.=C2=A0 Using it for anything other than ordering compa= rison is simply not viable, nor useful.=C2=A0 It's defining a custom im= plementation if a specific pre-existing action.

For all the other operators, the logic seems to be defined for an operator,= the behavior of which is "whatever makes sense in your use case, idk.= "=C2=A0 That is, to use Rowan's distinction, a philosophically dif= ferent approach.=C2=A0 Not a bad one, necessarily.=C2=A0 In fact, I think i= t's a very good one.

But, as they are different, perhaps that suggests that comparison should in= stead not be implemented as an operator overload per se, but as a named mag= ic method.=C2=A0 The existing logic for it is, I think, fine, but it's = a fair criticism that you're not defining "what happens for a meth= od-ish named <=3D>", you're defining "how do objects co= mpare."=C2=A0 So I think it would make sense to replace the <=3D>= ; override with a `__compare(mixed $other): int`, which any class could imp= lement to opt-in to ordering comparisons, and thus work with <, >, = =3D=3D, <=3D>, etc.=C2=A0 (And, importantly, still keep the "spe= cify the type(s) you want to be able to compare against" logic, alread= y defined.)

A similar argument could probably be made for =3D=3D, though I've not f= ully thought through if I agree or not.=C2=A0 Again, I think the previously= defined logic is fine.=C2=A0 It would be just changing the spelling from `= operator =3D=3D(mixed $other): bool` to `public function __equals(mixed $ot= her): bool`.=C2=A0 But that again better communicates that it is a core lan= guage behavior that is being overridden, rather than an arbitrarily defined= symbol-function-thing with domain-specific meaning.

There was an RFC for a Comparable interface back in the stone age (2010), b= ut it looks like it never went to a vote: https://wiki.php.net/rf= c/comparable

Arguably, this would then make more sense as a stand-alone RFC that happens= to reuse a lot of the existing code and logic defined for operator overloa= ds, which are all still just as valid.

That does not apply to the arithmetic, bitwise, or logic operators.=C2=A0 O= verriding + or / for a specific domain is not the same, as you're not h= ooking into engine behavior the way <=3D> or =3D=3D are.=C2=A0 For th= ose, I'd prefer to stick to the current/previous implementation, with t= he `operator` keyword, for reasons I explained before.

Jordan, does that distinction make sense to you?

--Larry Garfield

Yes, I certainly under= stand the distinction. The RFC does not treat all operators equally. For ma= ny of them, the only opinion it holds is whether or not the operator is una= ry or binary, which is something enforced by the compiler anyway. But for c= omparisons, the RFC went out of its way to ensure that the overloads cannot= repurpose any comparisons for non-comparison, non-ordering tasks usefully = (as far as return value goes). In that sense, yes, I see how that feels mor= e like an operation instead of an operator.

The on= ly hesitation I would have about that is the clunky/ugly feeling I get of h= aving some of them be symbols and some of them be names for a reason that w= ill be totally inscrutable to 95% of developers and just be "one of th= ose PHP quirks". In principle though, I do get what you're saying = here.

Jordan
--000000000000b5e00406225bd883--