-
-
Notifications
You must be signed in to change notification settings - Fork 59
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
MetadataGenerator name collisions #233
Comments
We have workaround for KontaktIO (0f67a2b), but it is dirty solution. We just hardcode the names of the protocols which are in collision in our metadata generator. The solution is temporary until we find a better one. |
It seems that Swift has similar problems: Case 1char *timezone(int, int);
extern long timezone; print(timezone) // Ambiguous use of 'timezone'` Case 2@protocol MyName
+ (void)method;
@end
@protocol MyNameProtocol
+ (void)method1;
@end
@interface MyName : NSObject
@end In this case the So for this issue I suggest that we automatically append only one |
Sounds fine to me. |
What do you think to report errors at runtime, instead of build time. Because we may sometimes fail the build, but if the user doesn't access this API, he wouldn't be able to use the other 99% of the library. |
How would we know at runtime that there has been a name collision at build time? |
We could mark the name in the metadata that it is ambiguous or something. |
With a flag, perhaps? Alright, I think this will work. |
Those are some implementation details. Lets clear the use case first :) |
Fixed in #299 |
From to-do in Meta/IdentifierFactory.cpp#L9
Reproduced with the KontaktSDK
In the metadata generator there are some static maps that contains hardcoded symbol names from the iOS SDK for which we know there is conflict in their JS name and must be renamed. Maybe there is better way to pass this map to the IdentifierGenerator. For third-party libraries the map may be parsed from file or something more flexible.
The most easy to consume way is if they can be generated from the decls, this won't involve manual setup. However it also involves some magic. Developers should be notified for such collisions and the way they are resolved. e.g. trace that: the TKTRegion interface collides with the TKTRegion protocol and the protocol is renamed to TKTRegionProtocol.
The text was updated successfully, but these errors were encountered: