-
-
Notifications
You must be signed in to change notification settings - Fork 135
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
Static binding generator creates wrong files, when two extended classes have the same name #692
Comments
For now we'll issue a warning the identical names will be created and that will cause an undefined behavior. In this case the build will crash and recommend workaround options. |
this problem is explained in detail in issue #692 also did a clean of generated bindings
this problem is explained in detail in issue #692 also did a clean of generated bindings
This is causing a problem even without uglifying, because the names have to be globally unique. That means if I use a name that's already been used somewhere in another module, I will hit the same issue because everything passes through the same line in ts_helpers. |
That's great news, thanks! |
Remove RfT label beacuse the fix is reverted. |
This is fixed and will be available in the next official release of |
Problem:
Static binding generator creates wrong files, when two extended classes have the same name
How can I reproduce the problem:
https://github.com/NativeScript/NativeScript/blob/84c469d61b148544bd1ef8b4f41ce689f9145754/tns-core-modules/ui/gestures/gestures.android.ts#L198
https://github.com/NativeScript/NativeScript/blob/84c469d61b148544bd1ef8b4f41ce689f9145754/tns-core-modules/ui/gestures/gestures.android.ts#L339
SwipeGestureListener
andTapAndDoubleTapGestureListener
becomee
or some other letter.GestureDetector_SimpleOnGestureListener_frnal_ts_helpers_l58_c38__e.java
.The name is generated as follows:
<extended_class_name>_f<file_path>_l<line>_c<column>__<unique_name>.java
<extended_class_name>
_f<file_path>_l<line>_c<column>
.<unique_name>
is not so unique anymore.Solution
There are two general paths we can take:
<unique_name>
so it stays uniqueThis problem does not happen when extending an interface, because the native implementation name does not take part in finding the js counterpart implementation, and all can use the same implementation of an interface.
The text was updated successfully, but these errors were encountered: