-
-
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
Classes can implement multiple interfaces #501
Conversation
💚 |
👍 |
@Pip3r4o can we rename "interfaces" to "implements" com.a.b.ClassToExtend.extend({ ClassToExtendMethod1: function() { // overrides method of class ClassToExtend interface1Method1: function(p1, p2) { ... }, // implement methods from Interface1 interface2Method1: function() { ... }, // implement methods from Interface2 or better we can move this to the extend function arguments as such interface1Method1: function(p1, p2) { ... }, // implement methods from Interface1 interface2Method1: function() { ... }, // implement methods from Interface2 Since this is leaked to runtime functions like getOwnProperties etc @NativeScript/android-runtime Share you comments on this |
💚 |
run ci |
💔 |
This makes sense as Java doesn't support explicit interface implementations (e.g. resolve method collision). |
@slavchev which one ? |
@blagoev, I am up for using 'implements' so long as we are okay having 2 On Friday, 1 July 2016, blagoev [email protected] wrote:
Sincerely, |
My vote goes for consistency with the iOS Runtime. The closer API-wise both Runtimes are, the better. |
ok thanks @Pip3r4o ignore this suggestion |
I was referring to avoid interface method collision. As for the syntax, I cannot state some preference or opinion as long we avoid interface method collision. |
Must have remembered it wrong. Then yes, @blagoev's suggestion makes sense On Friday, 1 July 2016, Georgi Atanasov [email protected] wrote:
Sincerely, |
In past we had some concerns about |
One note on the suggestion: If we keep the interfaces member as part of the implementation object it means one should write in TypeScript something like this class MyActivity extends Activity implements CallbackHandler which results in JavaScript In either case our current approach will not work If we move this as extends argument it will be possible to support decorators for the interfaces in Typescript like so @interface(CallbackHandler) or there is some other idea to support the proposed syntax from TypeScript |
Ultimately my thinking is to start analyzing TypeScript code for extends (especially since there is public TS compiler API available) then we will not have this problem of supporting TypeScript extends and implements through our JavaScript syntax and will remove any redundant declarations in the form of decorators and other hacks we are currently doing |
@slavchev My suggestion was to be on par with the A.B.C.extend so "implement" is the correct word. If we decide to rename "interfaces" |
Ok the other idea is to handle this using decorators that will inject the interfaces member on the implementation object before calling extend so this will work out of the box @interface(CallbackHandler) |
Using a decorator sounds like a good idea and should be easy enough to implement in the runtime binding generator, and shouldn't take a lot of effort to write in the SBG either. |
run CI |
run ci |
💔 |
run ci |
💚 |
87e579e
to
68a7155
Compare
💚 |
I have since updated the static binding generator to support @Interfaces([a.b.C]) decorator syntax in typescript, this is being tested for the runtime binding generator and will soon be pushed. I stuck with |
👍 |
1 similar comment
👍 |
💔 |
💚 |
e5519f0
to
0f8bc97
Compare
💚 |
0f8bc97
to
ead0e8b
Compare
💔 |
💚 |
Description
With the following changes, and those in the android-static-binding-generator repo, full support to implementing interfaces will be enabled. The supported syntax is as follows:
Suppose we have the following interfaces and classes:
Javascript
Typescript
The resulting extended class will be implementing both interfaces declared in the interfaces array.
Notable changes in files
Does your commit message include the wording below to reference a specific issue in this repo?
Addresses issue #442
Related Pull Requests
repo: android-static-binding-generator, PR: 10 - contains the SBG logic, while the changes to the runtime binding generator in this repository mimic it.
Does your pull request have [unit tests]?
No unit tests as the functionality is difficult to unit test with the current test structure. A sample repo demonstrates the new functionality by extending object and implementing multiple interfaces. To further verify that the correct class is generated you can fetch the
.dex
from the application folder,d2j
it and explore its contents.ping: @NativeScript/android-runtime