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

Common Initializers #5

Open
markavitale opened this issue Jun 5, 2020 · 0 comments
Open

Common Initializers #5

markavitale opened this issue Jun 5, 2020 · 0 comments
Labels
proposed convention A new convention for the guidelines

Comments

@markavitale
Copy link
Contributor

Convention

When there is more than one way to init an object (e.g. initWithFrame, initWithCoder) and these perform common routines (such as setting ivars, sizing, etc.), consider using c-style function to perform to handle this vs. an Obj-C function.

Rationale

Particularly if the name is a common one (e.g. initCommon:, etc.), there is some risk that the function could be overridden without calling super.

Example

@implementation XYZView

void XYZCommonInit(XYZView *self) {
  // ...
}

- (instancetype)initWithFrame:(CGRect)frame {
    // ...
   XYZCommonInit(self);
   return self;
}
- (instancetype)initWithCoder:(NSCoder *)coder {
    // ...
   XYZCommonInit(self);
   return self;
}
@end

Note:
Could put a bit of discussion in the rationale about how this truly applies to any private selector but in practice we have hit the common initializer case more than anything else. We can even add that if shipping a framework, private functionality of anything publicly exposed for subclassing should potentially avoid private selectors and stick to C-style functions to prevent clients of your framework from unintentionally overriding private functionality.

@markavitale markavitale added the proposed convention A new convention for the guidelines label Jun 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposed convention A new convention for the guidelines
Projects
None yet
Development

No branches or pull requests

1 participant