CODEWITHSUNDEEP
swift
user2912108
user2912108

Reputation: 737

Swift namespace conflict perfect storm

I'm 90+% certain that this is a loophole in the language design that makes this type now completely inaccessible.

My own project has a class Analytics. The 3rd party cocoapod that I'm using also has a MODULE named Analytics. INSIDE this module, somebody decided to use NS_SWIFT_NAME to "rename" the internal ObjC SEGAnalytics class to.. you guessed it.. Analytics. So we have my own Analytics class, a module named Analytics and an exported class of that module named Analytics, but only indirectly.

The problem:

If I need to (and I do) access Analytics.SEGAnalytics from one of my files, the ONLY time swift will even consider that Analytics is referring to a module, is through the import statement, import class Analytics.SEGAnalytics. HOWEVER, once I try to use the type like so SEGAnalytics.shared.identify(), the compiler complains that "SEGAnalytics" has been renamed to Analytics". If I try to comply, Analytics ends up resolving to my own class type. If I try to disambiguate through Analytics.SEGAnalytics.identify() or Analytics.Analytics.identify(), the very first Analytics type is not interpreted as a module, but my own class type and fails.

The only solution that I can think of is to rename my own heavily Analytics class which is not acceptable. Cue the "if this was C++, this problem would have been solved in less than 5 min" speech.. :|

Upvotes: 1

Views: 114

Answers (1)

user2912108
user2912108

Reputation: 737

Okay. Workaround in place, possibly only one. I used ObjC to re-expose the class static methods via a disambinguated wrapper class and then exposed that back to my main app via standard bridging header.

Upvotes: 1

Related Questions