Skip to content

Add missing protocol to fix Xcode 12.5 warning #7943

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.

Sign up for GitHub

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

Merged
merged 3 commits into from
Apr 23, 2021
Merged

Add missing protocol to fix Xcode 12.5 warning #7943

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c5ef486
Add missing cast to fix Xcode 12.5 warning
paulb777 Apr 23, 2021
f3122c0
review
paulb777 Apr 23, 2021
783f185
style
paulb777 Apr 23, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion FirebaseDatabase/Sources/Login/FIRDatabaseConnectionContextProvider.m
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -217,7 +217,9 @@ - (void)listenForAppCheckTokenChanges:(fbt_void_nsstring)listener {
+ (id<FIRDatabaseConnectionContextProvider>)
contextProviderWithAuth:(nullable id<FIRAuthInterop>)auth
appCheck:(nullable id<FIRAppCheckInterop>)appCheck {
return [[self alloc] initWithAuth:auth appCheck:appCheck];
return (id<FIRDatabaseConnectionContextProvider>)[[self alloc]
Copy link
Contributor

@maksymmalyhin maksymmalyhin Apr 23, 2021

Choose a reason for hiding this comment

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

Thank you for catching this. I think we should add confirmation of FIRDatabaseConnectionContextProvider class to FIRDatabaseConnectionContextProvider protocol in the header instead of casting. It seems that originally the method could return different classes but it is not the case any more, so an explicit confirmation looks reasonable to me.

cc @schmidt-sebastian

Copy link
Member Author

@paulb777 paulb777 Apr 23, 2021

Choose a reason for hiding this comment

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

@maksymmalyhin It looks like the unit tests depend on the different classes:

Screen Shot 2021-04-23 at 7 57 28 AM

Copy link
Contributor

@maksymmalyhin maksymmalyhin Apr 23, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

Yeah, that's correct. Sorry if I was not clear. Let me try to explain my thoughts.

The warning with the original method implementation is actually correct an helpful, because the method is supposed to return an instance that conforms to the FIRDatabaseConnectionContextProvider protocol, but in fact it returns an instance of FIRDatabaseConnectionContextProvider class (the same name as the protocol to add more confusion 😄 ) which doesn't declare it's conforming to the protocol. My suggested fix for this is adding the protocol confirmation to the class, e.g. by modifying

firebase-ios-sdk/FirebaseDatabase/Sources/Login/FIRDatabaseConnectionContextProvider.h

Line 59 in e4dcb85

@interface FIRDatabaseConnectionContextProvider : NSObject
to the following:

@interface FIRDatabaseConnectionContextProvider : NSObject <FIRDatabaseConnectionContextProvider>

In this case casting won't be required and if protocol changes the compiler will suggest us changing the class (which is not the case currently). I needed to do this initially, but missed it, sorry about that.

WDYT?

Copy link
Member Author

@paulb777 paulb777 Apr 23, 2021

Choose a reason for hiding this comment

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

Thanks for explaining. That makes sense and is much cleaner to avoid the casts.

I was confused by the same name for both the protocol and the interface. Is that a typical style?

Copy link
Contributor

@maksymmalyhin maksymmalyhin Apr 23, 2021

Choose a reason for hiding this comment

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

I usually prefer to add Protocol suffix if there is a name conflict with a class, but here I followed the existing name convention and only applied renaming "AuthTokenProvider" -> "ConnectionContextProvider". I actually don't mind renaming the protocol.

initWithAuth:auth
appCheck:appCheck];
}

@end
Expand Down