On Fri, Aug 6, 2021, at 3:18 PM, Scott Arciszewski wrote:
> My recommendation is to have a base interface for every operator that can
> be overloaded, so that these can be composed together.
>
> AddOverloadInterface { __overloadAdd(): self; }
> SubOverloadInterface { __overloadSub(): self; }
> MulOverloadInterface { __overloadMul(): self; }
> DivOverloadInterface { __overloadDiv(): self; }
> ModOverloadInterface { __overloadMod(): self; }
> LeftShiftOverloadInterface { __overloadLeftShift(): self; }
> RightShiftOverloadInterface { __overloadRightShift(): self; }
> XorOverloadInterface { __overloadXor(): self; }
> etc.
>
> Then if you were implementing matrix math, you could do this:
>
> MatrixMath implements AddOverloadInterface, SubOverloadInterface,
> MulOverloadInterface {
>
> }
That would be roughly how Stringable/__toString works now. I'd be OK with
that, if it's going to be a language trend.
> This prevents you from having to define methods for operations you don't
> support.
>
> It's probably worth exploring whether common combinations are worth
> defining for convenience.
Now that intersection types are a thing, I don't think combo interfaces are
worth much here. If anything, it would be just more impetus for type aliases
to reduce typing. (Human typing, I mean, not code typing.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
