Hi! > I think if you want to push the RFC forward, a really quite strong > case needs to be made for why having it be a language level feature is > so much better (or even at all better) than having it be implemented > in userland.
I tend to agree here. There are not that many cases where < and > are natural for objects - mostly for implementation of extended numeric types like complex numbers, but that's not a very common thing people do in PHP. And when they do, they usually come with custom methods, since these types work different from scalar types. Sorting may be a major use case, but there I think using custom sort functions have it covered. So I'd like to see more specifically on the case why it's important to have operators and not specialized methods for objects in the RFC. Especially for </> kind - I can see some case for non-strict equality, but ordering seems to be a bit exotic (I may be missing some cases though). There are also some complications there. I.e., if you implement both __compare and __equals, you essentially have two functions that do "equals" - you probably won't want to call both for something like >=? But that creates an opening for very weird bugs. Also note: Python had __cmp__ in Python 2, but they moved away from it to specialized comparison methods in Python 3. It would be a good idea to look into why they did it, so we could learn from their experience. Doesn't mean our decision would be the same, but it looks like they had something that made them change it, so I think we should at least consider what it was. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
