Re: [PHP-DEV] Operator overloading for userspace objects

On 06/02/2020 20:06, Andrea Faulds wrote: Haskell has a nice approach (probably some other languages have this too) where it has typeclasses that contain related operators, which means that e.g. if you want to overload +, your type needs to support Num which also contains -, *, abs, the sign

Re: [PHP-DEV] Operator overloading for userspace objects

Hi Johannes, Thank you for your points! I think you point out some overlooked issues. Johannes Schlüter wrote: Which one is being called? - Vector's or Matrix's. How will your vector know about my Matrix? The way C++ solves this is by allowing non-member functions as operators.

Re: [PHP-DEV] Operator overloading for userspace objects

On Wed, 2020-01-29 at 00:14 +0100, jan.h.boeh...@gmx.de wrote: > the last days I have experimented a bit with operator overloading in > userspace classes (redefing the meaning of arithmetic operations like Some historic context: I am probably the one who did operator overloading in PHP first.

Re: [PHP-DEV] Operator overloading for userspace objects

On Fri, Jan 31, 2020 at 10:55 AM Ben Ramsey wrote: > > Also, I want to reiterate: Any of these operations MUST be designed to > return a new value, never modify in place. These operators only make sense > on value objects, not service objects, and value objects should be > immutable. > > I

Re: [PHP-DEV] Operator overloading for userspace objects

Hi, Nikita Popov wrote: Yes, i don't think it makes sense to group these operations in interfaces, the use-cases are just too diverse. It's possible to define one interface per operator (e.g. what Rust does), though I don't think this is going to be particularly useful in PHP. I would not want

Re: [PHP-DEV] Operator overloading for userspace objects

Hi Jan, On 28/01/2020 23:14, jan.h.boeh...@gmx.de wrote: the last days I have experimented a bit with operator overloading in userspace classes (redefing the meaning of arithmetic operations like +, -, *, etc. for your own classes). Thanks for bringing this up, and starting to dig into the

RE: [PHP-DEV] Operator overloading for userspace objects

On Sat, Feb 1, 2020 10:22 AM wrote: > Looks much better! If you submit a pull request, I can leave some more > detailed comments. Okay, I will submit a pull request with my changes. > If you would like to start an RFC on this topic, please sign up for a wiki > account

Re: [PHP-DEV] Operator overloading for userspace objects

On Thu, Jan 30, 2020 at 10:22 PM wrote: > > Unfortunately, this implementation goes in the wrong direction: PHP > already has full internal support for operator overloading through the > do_operation object handler. Operator overloading should be exposed to > userland through that handler as

Re: [PHP-DEV] Operator overloading for userspace objects

On Fri, Jan 31, 2020, at 11:32 AM, Mike Schinkel wrote: > > On Jan 31, 2020, at 10:41 AM, Larry Garfield wrote: > > > > I cannot speak to the implementation details. From a design perspective, I > > am tentatively positive on operator overloading, with separate method for > > each operator,

Re: [PHP-DEV] Operator overloading for userspace objects

> I cannot speak to the implementation details. From a design perspective, I am tentatively positive on operator overloading, with separate method for each operator, BUT, the big question for me is the rules around type compatibility. > > Can you only compare 2 of the same type? What about

Re: [PHP-DEV] Operator overloading for userspace objects

> If we still want operator overloading and we want to force operator > overloading to require immutability, I believe that means we would need an > immutability RFC to be approved (and implemented?) before operator > overloading requiring immutability could be approved. Something like this:

Re: [PHP-DEV] Operator overloading for userspace objects

> On Jan 31, 2020, at 10:41 AM, Larry Garfield wrote: > > I cannot speak to the implementation details. From a design perspective, I > am tentatively positive on operator overloading, with separate method for > each operator, BUT, the big question for me is the rules around type >

Re: [PHP-DEV] Operator overloading for userspace objects

I like this whole operator overloading thing. I would probably use it in brick/math and brick/money to replace verbose `->plus()`, `->multipliedBy()` etc. calls. > Can you only compare 2 of the same type? What about subclasses?

Re: [PHP-DEV] Operator overloading for userspace objects

> Also, I want to reiterate: Any of these operations MUST be designed to return > a new value, never modify in place. These operators only make sense on value > objects, not service objects, and value objects should be immutable. I completely agree. This was the gist of my earlier comments.

Re: [PHP-DEV] Operator overloading for userspace objects

On Thu, Jan 30, 2020, at 3:22 PM, jan.h.boeh...@gmx.de wrote: > > Unfortunately, this implementation goes in the wrong direction: PHP already > > has full internal support for operator overloading through the do_operation > > object handler. Operator overloading should be exposed to userland

RE: [PHP-DEV] Operator overloading for userspace objects

> Unfortunately, this implementation goes in the wrong direction: PHP already > has full internal support for operator overloading through the do_operation > object handler. Operator overloading should be exposed to userland through > that handler as well. I have made another implementation

RE: [PHP-DEV] Operator overloading for userspace objects

> I would recommend not handling overloading of comparisons in the same > proposal. Comparison is more widely useful than other overloading and has a > more complex design space (especially when it comes to accommodating objects > that can only be compared for equality/inequality for example).

Re: [PHP-DEV] Operator overloading for userspace objects

Would there be an RFC to push this feature(with the right handler, POC) into PHP? Or something would stop it from happening? On Wed, 29 Jan 2020, 10:20 am Nikita Popov, wrote: > On Wed, Jan 29, 2020 at 12:14 AM wrote: > > > Hello everybody, > > > > > > > > the last days I have experimented

Re: [PHP-DEV] Operator overloading for userspace objects

On Wed, Jan 29, 2020 at 12:14 AM wrote: > Hello everybody, > > > > the last days I have experimented a bit with operator overloading in > userspace classes (redefing the meaning of arithmetic operations like +, -, > *, etc. for your own classes). > > This could be useful for different libraries

Re: [PHP-DEV] Operator overloading for userspace objects

> On Jan 28, 2020, at 17:55, Michael Cordover wrote: > > On Tue, Jan 28, 2020, at 18:47, Ben Ramsey wrote: >> If you take mutation off the table, then things become easier, IMO. We >> only need two magic methods: >> >> * __toInteger(): int >> * __toFloat(): float >> >> Then, in any

Re: [PHP-DEV] Operator overloading for userspace objects

On Tue, Jan 28, 2020, at 18:47, Ben Ramsey wrote: > If you take mutation off the table, then things become easier, IMO. We > only need two magic methods: > > * __toInteger(): int > * __toFloat(): float > > Then, in any mathematical context, PHP could call the appropriate > method and use the

Re: [PHP-DEV] Operator overloading for userspace objects

> On Jan 28, 2020, at 17:14, > wrote: > > Hello everybody, > > > > the last days I have experimented a bit with operator overloading in > userspace classes (redefing the meaning of arithmetic operations like +, -, > *, etc. for your own classes). > > This could be useful for different

Re: [PHP-DEV] Operator overloading for userspace objects

I think that the left operand is the "owner", the magic method handler, while the right operand is the argument. So for $object * 5, we will have: // $object instance public function __multiply($number): self { return $this->multiply($number); } But for 5 * $object we will have an error.

[PHP-DEV] Operator overloading for userspace objects

Hello everybody, the last days I have experimented a bit with operator overloading in userspace classes (redefing the meaning of arithmetic operations like +, -, *, etc. for your own classes). This could be useful for different libraries which implements custom arithmetic objects (like money