On Fri, Aug 20, 2021 at 9:49 AM Larry Garfield <la...@garfieldtech.com> wrote:
> > - The "Separate codebases" risk is odd. As you note, "the same as > anything else, duh, copy-pasta will bite you." I'm not sure why that's > even listed. > > - The larger risk would be competing implementations that use operators > differently. Eg, I could see one collection implementation using / to > indicate "remove these elements" (because that's the complement of modulo, > which is "all elements except these"), and another to indicate "give me an > array of these many equally-sized collection objects." That would be > confusing if you bounce between two implementations on different projects. > (Eg, Laravel and Symfony.) (We could argue that one of those > implementations of / is dumb, but that doesn't mean they won't exist.) > > Agreed. I reworded and simplified that subsection. > - I don't really grok how $queue -= 1 would work. If that expands to > $queue = $queue - 1, then the = operator would return the value assigned > ($queue, after the value is removed), and you would get the next item... > how? I don't know how you'd do that, making that syntax nominally valid, > but useless. > I added more details to clarify what the example was actually about. It was *intended* to show how such usage is ambiguous and incorrect. Because a class that implements __sub() can't *prevent* it from also working with the reassignment operator -=, usage in this fashion will be either highly discouraged or loudly communicated by the library, which in either case should help promote good community standards around the feature. In this example, the __sub() method didn't return an instance of Queue, it was returning something like an array of `int` items from the queue, which obviously behaves terribly with the reassignment operator. > - "In Python, the comparison operators are not directly commutative, but > have a reflected pair corresponding with the swapped order. However, each > object could implement entirely different logic, and thus no commutativity > is enforced. " > > I... have no idea what that sentence means. Please clarify. > I added a more explicit explanation of this. Basically, comparisons are not "commutative". They have a reversed relationship with some other comparison. `$x > $y` gets *reflected* to `$y < $x`. Equality comparison is its own "reflection". The reflection for the spaceship operator is `$x <=>$y === ($y <=> $x) * -1`. > - It doesn't seem to be explicitly stated, but I presume developers can > type their operator methods as `mixed` if they are so inclined? (I don't > see why they would, but they could.) > Yes, they are not prevented from doing this, but they must do so explicitly with the `mixed` literal when typing the parameter. The return value is not forced to be typed (that is, no type declaration is treated like mixed, even though in the engine it's a separate flag), but can also be mixed if they wish. - You refer to InvalidOperator as an exception, although it extends Error. > That's technically incorrect. It is a new *throwable*, which extends > error. Please use the correct terms. (The design is fine, IMO, but it > should have the correct terminology.) > Thanks. I've cleaned up all the references I believe. - I think sticking to compareTo() is probably wise. I can see all sorts of > abuses of the other comparison operators if they were allowed... and I'd > probably do some of that abuse myself, frankly. :-) > > - Please make sure via tests that __compareTo() is triggered by sort() and > friends, as that's the main use case for it: Making sorting objects just > like sorting anything else, without having to provide a separate, > independent comparison algorithm. (Basically, replacing usort() with > __compareTo().) > Yes, I have three existing tests in the engine to resolve, then I will move on to improving and expanding the tests for this feature. :) > > Open questions: > > > > - Should this RFC include the bitwise operators or remain limited to the > > minimal set of math operators? > > This should IMO be decided based on how easy they are to implement. If > it's trivial to include, and uncontroversial, sure. If it's contentious or > hard, punt to a later RFC. > They are very trivial to implement. If anyone has an objection to this specifically, I'll of course take that into consideration. I am not planning on entertaining the idea of any of the miscellaneous operators, reassignment operators, or logical/boolean operators in this RFC though. That seems too free form, especially when the PHP community won't have any pre-established community standards around using them prior to this feature. > > - Should the == operator fail-over to existing behavior for all classes > if > > unimplemented, not just internal ones? (This would reduce BC break, but > > make catching implementation errors more difficult for userland code.) > > It would help if you documented the current behavior in the RFC, because I > had to go test it to see what it was. :-) > > I'd say yes, keep the existing behavior. I actually have a few tests > right now in a serialization library that check if $foo == > unserialize(serialize($foo)); (Not those functions, but in concept.) > Yes, I actually already committed the change for this and updated the RFC. There are too many problems involved in trying to error unimplemented == operators, and that might not be desirable behavior anyways. Jordan
