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

MetadataGenerator name collisions #233

Closed
PanayotCankov opened this issue Jul 20, 2015 · 9 comments
Closed

MetadataGenerator name collisions #233

PanayotCankov opened this issue Jul 20, 2015 · 9 comments

Comments

@PanayotCankov
Copy link
Contributor

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.

@ivanbuhov
Copy link
Contributor

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.

@jasssonpet jasssonpet assigned jasssonpet and unassigned ivanbuhov Aug 24, 2015
@jasssonpet
Copy link
Contributor

It seems that Swift has similar problems:

Case 1

char *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 MyName protocol isn't visible in swift.

So for this issue I suggest that we automatically append only one Protocol suffix at the end, if there is collision between an interface and a protocol and print errors for all other cases, to avoid the ambiguity.

@fealebenpae
Copy link
Contributor

Sounds fine to me.

@jasssonpet
Copy link
Contributor

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.

@fealebenpae
Copy link
Contributor

How would we know at runtime that there has been a name collision at build time?

@jasssonpet
Copy link
Contributor

We could mark the name in the metadata that it is ambiguous or something.

@fealebenpae
Copy link
Contributor

With a flag, perhaps? Alright, I think this will work.

@jasssonpet
Copy link
Contributor

Those are some implementation details. Lets clear the use case first :)

@fealebenpae fealebenpae modified the milestones: 1.4.0 (Under review), 1.3.0 Sep 3, 2015
@ivanbuhov ivanbuhov assigned ivanbuhov and unassigned jasssonpet Sep 7, 2015
@fealebenpae
Copy link
Contributor

Fixed in #299

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants