-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strict equality operator overloading for the \GMP class #13826
Comments
If do make such changes, how can we be sure that the GMP objects are exactly the same? Also, what is the difference between In any case, GitHub issues are not suitable for such discussions, so I encourage you to post your ideas on the mailing list. |
A GMP object is just a big integer representation of a number, and as such, the identity of one single instance of the object is a bit of a commodity. Any copy of the object that hold the same value is somewhat indistinguishable of another. Currently The I'll post it to the mailing list later, I agree it would be a breaking change that requires a proper discussion. |
Strict equality is not currently customizable in PHP, even in extensions. There's definitely a larger discussion required for something like this. Coincidentally, I'm working on data classes (i.e. classes as value types) which includes this feature (#13800). |
I'm closing the issue, as it's a subset of the one mentioned by @iluuu1994 |
Description
The GMP class already enjoys a lot of privileges in regards to having the language operators being overloaded under the hood to behave in a sensible way:
This is all good but the strict equality operator is the one that behaves in a weird way. While I do understand it would be bad to have \GMP { 0 } === int { 0 } to be true, I do think it's very odd that
gmp_init(0) === gmp_init(0)
evaluates to false.While I do understand they are different objects that have different pointers associated to them, I think this is just an interpreter implementation detail that shouldn't surface to the PHP user.
That kinda shuts down a more useful usage [IMO]: these are both the same number with the same type.
The text was updated successfully, but these errors were encountered: