Skip to content
This repository has been archived by the owner on Mar 3, 2020. It is now read-only.

Add nullability annotations to all APIs. #88

Merged
merged 3 commits into from
Mar 11, 2016
Merged

Conversation

nlutsenko
Copy link
Contributor

This adds nullability annotations to the entire API.
Everything is nonnull by default, unless otherwise specified.

Depends on #87 for latest Xcode in Travis.

cc @modocache

@kimon
Copy link
Contributor

kimon commented Mar 5, 2016

#87 is now merged in to master. let's pass CI and this is good to go.

@nlutsenko
Copy link
Contributor Author

Awesome. You are my goto reviewer now then.

@nlutsenko nlutsenko force-pushed the nlutsenko.nullability branch from 7604c93 to 78f1810 Compare March 5, 2016 01:31
@kimon
Copy link
Contributor

kimon commented Mar 5, 2016

👍

@nlutsenko nlutsenko assigned kimon and unassigned nlutsenko Mar 5, 2016
@nlutsenko
Copy link
Contributor Author

behold_ironman

@@ -59,7 +60,7 @@ typedef void (^FBKVONotificationBlock)(id observer, id object, NSDictionary *cha
@param block The block to execute on notification.
@discussion On key-value change, the specified block is called. In order to avoid retain loops, the block must avoid referencing the KVO controller or an owner thereof. Observing an already observed object key path or nil results in no operation.
*/
- (void)observe:(id)object keyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options block:(FBKVONotificationBlock)block;
- (void)observe:(nullable id)object keyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options block:(FBKVONotificationBlock)block;

Choose a reason for hiding this comment

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

Why is 'object' nullable? Are we explicitly allowing no-ops here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yup, inside implementation there is logic for bailing out early if the object is null.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can change it, but I think since we already are handling the null usecase, this is more permissive model. I don't feel strong about adding a constraint here, but we can defiently do it.

Choose a reason for hiding this comment

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

I just wonder wether this is a useful for the API to expose or not. Again, the eternal debate of "should nullable/nonnull imply runtime semantics" or not...

My thinking is that observe is something that only logically makes sense on a nonnull value, but considering the existing API is out there and implicitly deals with nil, maybe it makes sense to not force null checks on clients. Not sold either way.

@richardjrossiii
Copy link

Passing back to you for discussion.

@richardjrossiii
Copy link

Good discussion. Merge at will!

nlutsenko added a commit that referenced this pull request Mar 11, 2016
Add nullability annotations to all APIs.
@nlutsenko nlutsenko merged commit 43734da into master Mar 11, 2016
@nlutsenko nlutsenko deleted the nlutsenko.nullability branch March 11, 2016 06:23
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants