Skip to content
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

Merged
merged 7 commits into from
Apr 27, 2020

Conversation

dgelessus
Copy link
Collaborator

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.

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.
Copy link
Member

@freakboy3742 freakboy3742 left a 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.

changes/174.removal.rst Outdated Show resolved Hide resolved
rubicon/objc/runtime.py Outdated Show resolved Hide resolved
Copy link
Member

@freakboy3742 freakboy3742 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice clarifications; 🚢

@freakboy3742 freakboy3742 merged commit 36fa19b into beeware:master Apr 27, 2020
@dgelessus dgelessus mentioned this pull request May 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants