Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Friday, 20 September 2024 at 15:09, Christoph M. Becker wrote: > On 20.09.2024 at 15:00, Gina P. Banyard wrote: > > > This leads to a rather insane situation where the engine does not assume + > > is always commutative but does so for *, something which makes no sense as > > multiplication

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On 20.09.2024 at 15:00, Gina P. Banyard wrote: > This leads to a rather insane situation where the engine does not assume + is > always commutative but does so for *, something which makes no sense as > multiplication or product operations are (in the grand scheme of mathematics) > rarely commu

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Saturday, 14 September 2024 at 22:48, Jordan LeDoux wrote: > Hello internals, > > This discussion will use my previous RFC as the starting point for > conversation:https://wiki.php.net/rfc/user_defined_operator_overloads > > There has been discussion on list recently about revisiting the top

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Wed, Sep 18, 2024 at 6:11 PM Rowan Tommins [IMSoP] wrote: > On Wed, 18 Sep 2024, at 15:19, Christoph M. Becker wrote: > >> Maybe it would be "useful enough" to just restrict to left-hand side: > > > > In my opinion, this is the only reasonable way to implement operator > > overloads in PHP. I

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Wed, 18 Sep 2024, at 15:19, Christoph M. Becker wrote: >> Maybe it would be "useful enough" to just restrict to left-hand side: > > In my opinion, this is the only reasonable way to implement operator > overloads in PHP. It is easy to understand, and what can easily be > understood is easy to e

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On 18.09.2024 at 00:13, Rowan Tommins [IMSoP] wrote: > Since you mentioned Scala, I looked it up, and it seems to be on the > other end of the spectrum: operators are just methods, with no > mathematical meaning or special dispatch behaviour. In fact, "a plus b" > is just another way of writing "a

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Sat, Sep 14, 2024, at 4:48 PM, Jordan LeDoux wrote: > Hello internals, > > > This discussion will use my previous RFC as the starting point for > conversation: https://wiki.php.net/rfc/user_defined_operator_overloads Replying to the top to avoid dragging any particular side discussion into th

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Tue, Sep 17, 2024 at 6:49 PM 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 "operato

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

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

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

> On Sep 17, 2024, at 8:05 PM, Jordan LeDoux wrote: > On Tue, Sep 17, 2024 at 3:44 PM Mike Schinkel > wrote: > > Almost everything you have said are things that I have talked about or been > asked about for years. That is why I have been fairly dismissive about them

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Tue, Sep 17, 2024 at 3:44 PM Mike Schinkel wrote: > On Sep 17, 2024, at 6:04 AM, Andreas Leathley wrote: > > On 17.09.24 11:14, Mike Schinkel wrote: > > How would a developer know if they are using an object that has operators, > unless they study all the source code or at least the docs (ass

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Wed, Sep 18, 2024, at 01:12, K Sandvik wrote: > Operator overloading is indeed a very overloaded topic concerning computer > languages. > > But my 0.02 cents is that it's a good thing to have provided it solves one or > more of the problems such as: Hey Kent, > * Will the code be easier

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

Operator overloading is indeed a very overloaded topic concerning computer languages. But my 0.02 cents is that it's a good thing to have provided it solves one or more of the problems such as: * Will the code be easier to write, maintain, and read? * Will this help with optimizations? * Will

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

> On Sep 17, 2024, at 6:04 AM, Andreas Leathley wrote: > > On 17.09.24 11:14, Mike Schinkel wrote: >> How would a developer know if they are using an object that has operators, >> unless they study all the source code or at least the docs (assuming there >> are good docs, which there probably a

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On 17/09/2024 21:37, Rob Landers wrote: I would prefer to see something simple, and easy to reason about. We can abuse some mathematical properties to result in something quite simple: 1. If both are scalar, use existing logic. 2. If one is scalar and the other is not, use existing logic. 3

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On 2024-09-18 05:43, Jordan LeDoux wrote: The problem I was trying to solve involved lots of things that cannot be represented well by primitive types (which is presumably why they are classes in the first place). Things like Complex Numbers, Matrices, or Money. Money can be converted to a f

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Tue, Sep 17, 2024, at 21:25, Rowan Tommins [IMSoP] wrote: > On 17/09/2024 18:15, Jordan LeDoux wrote: >> >>> 1. Are we over-riding *operators* or *operations*? That is, is the user >>> saying "this is what happens when you put a + symbol between two Foo >>> objects", or "this is what happen

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Tue, Sep 17, 2024 at 12:27 PM Rowan Tommins [IMSoP] wrote: > On 17/09/2024 18:15, Jordan LeDoux wrote: > > > 1. Are we over-riding *operators* or *operations*? That is, is the user >> saying "this is what happens when you put a + symbol between two Foo >> objects", or "this is what happens whe

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On 17/09/2024 18:15, Jordan LeDoux wrote: 1. Are we over-riding *operators* or *operations*? That is, is the user saying "this is what happens when you put a + symbol between two Foo objects", or "this is what happens when you add two Foo objects together"? If we allow deve

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

> On Sep 17, 2024, at 11:11, Jordan LeDoux wrote: > > > > On Tue, Sep 17, 2024 at 10:55 AM Davey Shafik > wrote: >> >> >>> On Sep 17, 2024, at 10:15, Jordan LeDoux >> > wrote: >>> >>> >>> >>> On Tue, Sep 17, 2024 at 1:18 AM Ro

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Tue, Sep 17, 2024 at 10:55 AM Davey Shafik wrote: > > > On Sep 17, 2024, at 10:15, Jordan LeDoux wrote: > > > > On Tue, Sep 17, 2024 at 1:18 AM Rowan Tommins [IMSoP] < > imsop@rwec.co.uk> wrote: > >> On 14/09/2024 22:48, Jordan LeDoux wrote: >> > >> > 1. Should the next version of this RF

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

> On Sep 17, 2024, at 10:15, Jordan LeDoux wrote: > > > > On Tue, Sep 17, 2024 at 1:18 AM Rowan Tommins [IMSoP] > wrote: >> On 14/09/2024 22:48, Jordan LeDoux wrote: >> > >> > 1. Should the next version of this RFC use the `operator` keyword, or >> > should that

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Tue, Sep 17, 2024 at 2:56 AM Lynn wrote: > > > On Sat, Sep 14, 2024 at 11:51 PM Jordan LeDoux > wrote: > >> Hello internals, >> >> This discussion will use my previous RFC as the starting point for >> conversation: https://wiki.php.net/rfc/user_defined_operator_overloads >> >> There has been

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Tue, Sep 17, 2024 at 2:14 AM Mike Schinkel wrote: > > On Sep 17, 2024, at 1:37 AM, Jordan LeDoux > wrote: > > On Mon, Sep 16, 2024 at 9:35 PM Mike Schinkel > wrote: > > > > Yes, if constraints of the nature I propose below are adopted. > > > > The biggest problem I have with operator overloa

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Tue, Sep 17, 2024 at 1:18 AM Rowan Tommins [IMSoP] wrote: > On 14/09/2024 22:48, Jordan LeDoux wrote: > > > > 1. Should the next version of this RFC use the `operator` keyword, or > > should that approach be abandoned for something more familiar? Why do > > you feel that way? > > > > 2. Should

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On 14.09.24 23:48, Jordan LeDoux wrote: 1. Should the next version of this RFC use the `operator` keyword, or should that approach be abandoned for something more familiar? Why do you feel that way? 2. Should the capability to overload comparison operators be provided in the same RFC, or would

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On 17.09.24 11:14, Mike Schinkel wrote: How would a developer know if they are using an object that has operators, unless they study all the source code or at least the docs (assuming there are good docs, which there probably are not?) How is that different from using a method on an object? Ope

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Sat, Sep 14, 2024 at 11:51 PM Jordan LeDoux wrote: > Hello internals, > > This discussion will use my previous RFC as the starting point for > conversation: https://wiki.php.net/rfc/user_defined_operator_overloads > > There has been discussion on list recently about revisiting the topic of > o

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

> On Sep 17, 2024, at 1:37 AM, Jordan LeDoux wrote: > On Mon, Sep 16, 2024 at 9:35 PM Mike Schinkel wrote: > > Yes, if constraints of the nature I propose below are adopted. > > The biggest problem I have with operator overloads is that — once added — all > code could potentially be "infected"

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On 14/09/2024 22:48, Jordan LeDoux wrote: 1. Should the next version of this RFC use the `operator` keyword, or should that approach be abandoned for something more familiar? Why do you feel that way? 2. Should the capability to overload comparison operators be provided in the same RFC, or

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Mon, Sep 16, 2024 at 9:35 PM Mike Schinkel wrote: > > Yes, if constraints of the nature I propose below are adopted. > > The biggest problem I have with operator overloads is that — once added — > all code could potentially be "infected" with operator overloads. However, > if the developer *us

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Mon, Sep 16, 2024, at 2:47 AM, Jordan LeDoux wrote: > On Sun, Sep 15, 2024 at 9:12 PM Larry Garfield wrote: >> >> The "multiply by -1 for <=>" bit I don't fully understand the point of. The >> RFC tries to explain, but I don't quite grok it. >> > > I will perhaps respond with more detail to

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

> On Sep 14, 2024, at 5:48 PM, Jordan LeDoux wrote: > > Hello internals, > > This discussion will use my previous RFC as the starting point for > conversation: https://wiki.php.net/rfc/user_defined_operator_overloads > > There has been discussion on list recently about revisiting the topic o

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Mon, Sep 16, 2024 at 6:08 AM Rob Landers wrote: > On Mon, Sep 16, 2024, at 09:47, Jordan LeDoux wrote: > > The reason for this was to prevent developers from creating situations > where `5 > $foo` is true and `5 < $foo` is true. > > > Just to point out: currently, PHP already does nonsensical

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Mon, Sep 16, 2024 at 6:52 AM Bilge wrote: > > > On Mon, 16 Sept 2024, 15:28 someniatko, wrote: > >> On behalf of all struggling PHP developers who would like to implement >> patterns like Value Objects, with custom equality criterias >> > > I seriously doubt anyone is struggling without this,

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Sat, 14 Sep 2024, Jordan LeDoux wrote: > I want to discuss what changes to the previous proposal people would > be seeking, and why. The most contentious design choice of the > previous proposal was undoubtedly the `operator` keyword and the > decision to make operator overload implementatio

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Mon, 16 Sept 2024, 15:28 someniatko, wrote: > On behalf of all struggling PHP developers who would like to implement > patterns like Value Objects, with custom equality criterias > I seriously doubt anyone is struggling without this, unless you care to provide proof to the contrary. I think t

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

> This discussion will use my previous RFC as the starting point for > conversation: https://wiki.php.net/rfc/user_defined_operator_overloads > There has been discussion on list recently about revisiting the topic of > operator overloads after the previous effort which I proposed was declined.

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Mon, Sep 16, 2024, at 09:47, Jordan LeDoux wrote: > The reason for this was to prevent developers from creating situations where > `5 > $foo` is true and `5 < $foo` is true. Just to point out: currently, PHP already does nonsensical comparisons: https://3v4l.org/BZfc8 Granted, it is 'techni

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Sun, Sep 15, 2024 at 12:52 AM Jordan LeDoux wrote: > > These changes could and should be provided independent of operator > overloads. Gina has been working on a separate RFC which would cover all > three of these issues. You can view the work-in-progress on that RFC here: > https://github.com

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Sun, Sep 15, 2024 at 9:12 PM Larry Garfield wrote: > > The "multiply by -1 for <=>" bit I don't fully understand the point of. > The RFC tries to explain, but I don't quite grok it. > > I will perhaps respond with more detail to the rest of your message later, but I wanted to address this spec

Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Sat, Sep 14, 2024, at 4:48 PM, Jordan LeDoux wrote: > Hello internals, > > > This discussion will use my previous RFC as the starting point for > conversation: https://wiki.php.net/rfc/user_defined_operator_overloads > > > There has been discussion on list recently about revisiting the topic >

[PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

Hello internals, This discussion will use my previous RFC as the starting point for conversation: https://wiki.php.net/rfc/user_defined_operator_overloads There has been discussion on list recently about revisiting the topic of operator overloads after the previous effort which I proposed was dec