-
-
Notifications
You must be signed in to change notification settings - Fork 52
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
Tighten API of send_message #174
Conversation
This feature is rarely used - it had only a single usage in the rubicon-objc codebase, and is probably even less used outside, because most code can use high-level ObjCClass method syntax instead of send_message. The few cases that used this behavior can be easily updated to use an explicit get_class or ObjCClass call instead, so there's not much benefit in having this special case in send_message.
restype defaulted to c_void_p, which is very rare as a return type for Objective-C methods. Most calls that use this default should actually use None (void) or objc_id instead, and those that really need a c_void_p restype can set it explicitly. argtypes defaulted to an empty list, which made it easy to accidentally pass all arguments using ctypes default argument conversions, which can lead to unexpected/incorrect type conversions depending on the method signature and the actual passed arguments. It's better to always explicitly list all argument types to ensure that they are converted and passed correctly.
Objective-C object pointers should always be stored as objc_id or a similar type, to avoid accidentally treating random pointers as Objective-C objects. The implicit cast from c_void_p was no longer used anywhere in the rubicon-objc codebase, as all of our APIs return Objective-C object pointers properly typed.
Previously send_message accepted more arguments than are specified in argtypes. This is useful when calling variadic methods, but is easy to misuse by accident, because extra arguments passed to non-variadic methods are silently ignored. Varargs now need to be passed as a list into a separate kwarg, which allows checking the number of non-variadic args against the number of argtypes.
The three branches were almost entirely identical - most of their contents can be pulled out of the branches.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is opinionated, but it helps when you have good opinions :-)
There's nothing here that particularly concerns me - it looks like a good tightening of arguments where it is entirely appropriate to do so, and a clarification of variadics in a way that removes a potential footgun.
The only real tweaks I can see are related to documentation - the formatting of the removal note, and some clarification around types in variadics. Adding something to the API docs about variadic handling would also be a nice touch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice clarifications; 🚢
This change is a little opinionated - it removes a couple of special features from
send_message
that, in my opinion, are either too error-prone or too rarely used to be worth the extra complexity. See the individual commits for explanations on why I think it would be best to remove each of these features.I'm open to feedback on these changes. If you think any of these features are legitimately useful and removing them would be a bad idea, please let me know.
Also, this is obviously a breaking change - it removes features that were previously documented and supported. As we're still before version 1.0, this is technically fine. I don't think any of these features are widely used enough to require a proper deprecation process, but I'm open to feedback here as well.