Re: [PHP-DEV] Revisiting Userland Operator Overloads

On Sun, Aug 8, 2021 at 9:52 AM Rowan Tommins wrote: > > Yes, and as I demonstrated, there are situations where some of the > operators are only meaningful for a subset of operands. Saying that a > Money object is "Multipliable" would also be "a lie", since multiplying > two Money objects together

Re: [PHP-DEV] Shut down gcov.php.net

On Wed, 4 Aug 2021, 14:25 Christoph M. Becker, wrote: > Hi all, > > I suggest to shut down altogether. It is barely > maintained for quite a while: PHP 7.4 builds are failing, and there are > no PHP 8.0 builds at all. We already run a coverage job on Azure[1], so > there

Re: [PHP-DEV] Revisiting Userland Operator Overloads

On 08/08/2021 16:39, Larry Garfield wrote: 1) Implementing an interface and stubbing out some methods is a lie. It's a lie the engine won't stop you from telling, but it's still a lie. If you only support addition and division, for instance (add to a collection and split a collection into sev

Re: [PHP-DEV] Revisiting Userland Operator Overloads

Responding to a bunch of people at once here, for simplicity: On Sat, Aug 7, 2021, at 7:04 PM, Jordan LeDoux wrote: > > The 4 arithmetic operators, concat, and compare. > > I would argue that both modulo and pow (% and **) are arithmetic operators > that should come with the basic four as well.

Re: [PHP-DEV] Revisiting Userland Operator Overloads

On 08/08/2021 08:41, Jordan LeDoux wrote: Off the top of my head here are some of the use cases that I think benefit greatly from this: - Complex number objects - Fractions objects - Matrix objects (math) - Vector objects (math) - Time/Date intervals - Collections - Arbitrary precision numbers (

Re: [PHP-DEV] Revisiting Userland Operator Overloads

On Sun, Aug 8, 2021 at 3:08 AM Deleu wrote: > I started reading this thread with a total bias against it and as I read > through it I can only imagine how painful and annoying it is to maintain a > math library in PHP. Operator Overloading is truly a marvelous piece of > functionality for that do

Re: [PHP-DEV] Revisiting Userland Operator Overloads

I started reading this thread with a total bias against it and as I read through it I can only imagine how painful and annoying it is to maintain a math library in PHP. Operator Overloading is truly a marvelous piece of functionality for that domain. However my biased still exists: it would be awf

Re: [PHP-DEV] Revisiting Userland Operator Overloads

On Sat, Aug 7, 2021 at 8:20 PM Mike Schinkel wrote: > > On Aug 7, 2021, at 10:28 AM, Larry Garfield > wrote: > I strongly echo Larry's concern here. > > While I tend to be one who wants more language features, not less, the > availability of unconstrained operator overloading can beckon an > ine

Re: [PHP-DEV] Revisiting Userland Operator Overloads

On Sat, Aug 7, 2021 at 8:26 PM Dusk wrote: > On Aug 7, 2021, at 15:28, Larry Garfield wrote: > > As an example here, time units. Adding two hour:minute time tuples > together to get a new time (wrapping at the 24 hour mark) is an entirely > reasonable thing to do. But multiplication and divisi