On Fri, Dec 15, 2023 at 2:10 AM G. P. B. <george.bany...@gmail.com> wrote: > > On Tue, 12 Dec 2023 at 21:00, Robert Landers <landers.rob...@gmail.com> wrote: >> >> On Tue, Dec 12, 2023 at 2:04 PM G. P. B. <george.bany...@gmail.com> wrote: >> > GMP supports operator overloading >> >> GMP kinda-sorta-most-of-the-time supports operator overloading. >> Sometimes ... it doesn't. I implemented a field library in PHP (for >> work a couple of years ago) and occasionally, overloading would cast >> things back to float/int and break the math. I don't have access to >> that code, so I don't have any examples readily available (and the >> fact that an extension can do overloading but we can't in user-land is >> a whole different can of worms which made this library ridiculously >> hard to work with -- we rewrote everything in Scala and never looked >> back). Needless to say, if I were to go into a project that required >> GMP, I wouldn't trust the overloading.
Hey Gina, > I have no idea how _this_ is possible considering GMP will happily throw type > errors left and right even in cases when it shouldn't. > If you encountered this, you should have submitted a bug report. > Because, using a potential bug as an excuse for not doing this is... weird? The issue should have been reproducible on a smaller scale, but it wasn't, thereby hinting that we were hitting some extremely rare edge case that may not be easily testable. The fact that we hit it, couldn't create a simple reproduction for reporting a bug, and you should, theoretically, be able to rely on your software to compute math correctly made that one person's argument: "Why don't we rewrite this in X?" that much more persuasive... > I have come around userland operator overloading with the proposal from > Jordan, but considering this hasn't passed it might take a while before > someone gives it a crack at it again. > And it has _always_ been a thing that the engine, and internal extensions, > can do more things than userland. > Especially nonsensical stuff like variadic parameters not at the end... Considering operator overloading has been declined twice (in 2021: https://wiki.php.net/rfc/user_defined_operator_overloads, and 2020 https://wiki.php.net/rfc/userspace_operator_overloading) for "reasons" has me thinking it probably won't be proposed again. With comments like: > it is not your implementation proposal, > but rather the concept per-se that IMO shouldn't land in the language nobody will likely ever try this again, at least in the foreseeable future. With comments like that, there is simply no way forward. There's no convincing (at least via email) and by that point, it's too late anyway, they already voted but didn't even show up for the discussion that happened for weeks. Literally wasting everyone's time. The only way we'd ever get something like this passed is if someone proposes an RFC that prevents people from voting based on political/personal reasons and restricts voting "no" to technical reasons only; or some voters reopen one of the original RFC's for a revote and leave it in the "Pending Implementation" section as needing an implementation. The fact that people can and do vote "no" for no other reason than they "don't like it" or they "don't want to use it" leaves a bad taste in my mouth. Robert Landers Software Engineer Utrecht NL -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
