> ) I know you're not alone in that feeling. If it turns out this is the majority view, I think it answers a couple of open questions: > > Overload methods should definitely be named after operations, not symbols, to remind people they are implementing addition, not giving new meaning to + > > They should probably be grouped into interfaces, which this RFC has so far resisted. How often does it make sense for a type to support addition but not subtraction, or multiplication but not division? Even more clearly, if a type claims to implement bitwise OR but not bitwise AND, NOT, and XOR, something is > definitely fishy. > > You can't stop people using overloading DSL-style, but you can make it obvious that it's not the intention of the feature (if we agree that it's not the intention; maybe some people here are really hoping to use it that way?)
On 16/02/2020 10:31, rowan.coll...@gmail.com wrote: Except for simple numbers, almost no mathematical objects define division (only some special matrices can be on the right hand of a division, and for vectors there is no definition for division at all). Also think of time differences: $datetime1 - $datetime2 results in a DateInterval, but $datetime1 + $datetime2 is not a meaningful operation (Datetime already has a diff() method that do this). Also it is not really possible to split multiplicative and additive methods into different behavior, as when $a implements Additive Behavior it should be possible to do an -$a, but because of the the way PHP compiles the code this becomes -1*$a. This is sufficient for almost all cases, but it would require that the code also provides an possibility to handle multiplication. In my opinion this would lead to that even if an object implements these interfaces, in many cases you cannot be sure that it really supports all operations, which would contradict the whole idea of defining interfaces. I wonder if it would be reasonable to allow voting between an interface approach and the "separate magic function for each operator" approach... Greetings, Jan Böhmer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
