On Sat, May 7, 2022, at 3:59 PM, Jordan LeDoux wrote: > Of the people who did vote no and also provided me feedback, there were > *mainly* three reasons given (some in public such as on this list, and some > in private in more direct conversation): > > 1. Math is not a valid use case. > 2. Operator overloading for objects is something I will vote against in any > context for any design, no matter the argument or evidence provided. > 3. Operator overloading presents problems for static analysis and tooling > which are more significant than the benefits. > > I could argue against all three positions, but as you noted, I don't think > argument or debate is really helpful right now. Instead I'd like to talk at > a more high level about what sort of long-term future PHP contributors and > voters see for objects when it comes to allowing developers to control > object behavior. > > I like the way you organized the different levels of support within the > feature, it's a good organizational structure for thinking about the > feature-set. Given the feedback though, I found myself a little concerned > that if I created a Level 1 proposal, it's very possible that the people in > groups 1 and 3 above might vote for it. However, in doing so it's also very > possible that all the use-cases those voters care about would then be > covered, and many would then block anything which helps use-cases they do > not commonly use. In essence, the particular feedback I received made me > concerned that passing a Level 1 RFC would basically guarantee that Level > 2+ would never happen until the voter base itself was significantly changed.
It's possible. However, it wouldn't be the first feature that has laid dormant for several years until the voting population turned over. (Scalar types and attributes are the first such examples that come to mind, but I'm sure there's others.) Also, not proposing level 1 on the grounds that it would reduce the argument for level 2/3 in the future would effectively be holding level 1 functionality "hostage" for the more advanced versions, which... would probably not work out well. :-) (Even if that's not your intent, it would come off that way.) Conversely, giving people a version or three to work with level 1 operator overloads may get more people comfortable with the concept and thus make them more amenable to levels 2 or 3 in the future. Whether there's enough support for level 1 for it to pass at the moment, I honestly don't know. > Even so... I think I agree with your suggestion at this point. At the very > least, even if my concern above was proven true, it would then at least be > *possible* for me to provide an extension for PHP which addresses some of > the shortcomings for math. > > The main issue when it comes to comparisons is addressed in the PR I > linked, which basically boils down to "for objects, it makes sense for > equatable and comparable to be separated sometimes". Whether this involves > a fall-through in the VM for objects as done in my linked PR, or involves > new handlers for objects as CMB commented on that PR instead, it's actually > a very minor change technically within the engine to implement Level 1 > support as you described it. > > Jordan I defer to you and others on the technical implementation, as it's well outside my wheelhouse. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php