Classes can implement multiple interfaces #501

petekanev · 2016-06-27T18:35:43Z

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:

com.a.b.C.Interface1 has methods interface1Method1(Object, int), interface1Method2(int, Object), interface1Method3(int)
com.c.d.D.C.Interface2 has methods interface2Method1(), interface2Method2(boolean)
com.a.b.ClassToExtend is the class for extension with methods 'ClassToExtendMethod1()', and 'ClassToExtendMethod2()'

Javascript

com.a.b.ClassToExtend.extend({
  interfaces: [com.a.b.C.Interface1, com.c.d.D.C.Interface2],

  ClassToExtendMethod1: function() { // overrides method of class ClassToExtend
  },

  interface1Method1: function(p1, p2) { ... }, // implement methods from Interface1
  interface1Method2: function(p1, p2) { ... },
  interface1Method3: function(p1) { ... },

  interface2Method1: function() { ... }, // implement methods from Interface2
  interface2Method2: function(p1) { ... }
}

Typescript

@Interfaces([com.a.b.C.Interface1, com.c.d.D.C.Interface2])
class MyExtendedClass extends com.a.b.ClassToExtend {
  ClassToExtendMethod1() { // overrides method of class ClassToExtend
  }

  interface1Method1(p1, p2) { ... } // implement methods from Interface1
  interface1Method2(p1, p2) { ... }
  interface1Method3(p1) { ... }

  interface2Method1() { ... } // implement methods from Interface2
  interface2Method2(p1) { ... }
}

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

ns-bot · 2016-06-27T18:39:22Z

💚

Plamen5kov · 2016-06-28T07:31:40Z

👍

blagoev · 2016-07-01T07:20:31Z

@Pip3r4o can we rename "interfaces" to "implements"

com.a.b.ClassToExtend.extend({
implements: [com.a.b.C.Interface1, com.c.d.D.C.Interface2],

ClassToExtendMethod1: function() { // overrides method of class ClassToExtend
},

interface1Method1: function(p1, p2) { ... }, // implement methods from Interface1
interface1Method2: function(p1, p2) { ... },
interface1Method3: function(p1) { ... },

interface2Method1: function() { ... }, // implement methods from Interface2
interface2Method2: function(p1) { ... }
}

or better we can move this to the extend function arguments as such
com.a.b.ClassToExtend.extend({
ClassToExtendMethod1: function() { // overrides method of class ClassToExtend
},

interface1Method1: function(p1, p2) { ... }, // implement methods from Interface1
interface1Method2: function(p1, p2) { ... },
interface1Method3: function(p1) { ... },

interface2Method1: function() { ... }, // implement methods from Interface2
interface2Method2: function(p1) { ... }
}, [com.a.b.C.Interface1, com.c.d.D.C.Interface2])

Since this is leaked to runtime functions like getOwnProperties etc

@NativeScript/android-runtime Share you comments on this

ns-bot · 2016-07-01T07:21:29Z

💚

vchimev · 2016-07-01T07:40:35Z

run ci

ns-bot · 2016-07-01T07:43:24Z

💔

slavchev · 2016-07-01T07:48:11Z

This makes sense as Java doesn't support explicit interface implementations (e.g. resolve method collision).

blagoev · 2016-07-01T07:49:07Z

@slavchev which one ?

petekanev · 2016-07-01T08:00:04Z

@blagoev, I am up for using 'implements' so long as we are okay having 2
distinct words for the same thing between the 2 runtimes as iOS currently
uses 'interfaces'

On Friday, 1 July 2016, blagoev notifications@github.com wrote:

@slavchev https://github.com/slavchev which one ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#501 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AJ-u2r-FnOfTVjPl9ESZAZINCzvziEouks5qRMZ2gaJpZM4I_YRy
.

Sincerely,
Pete.

atanasovg · 2016-07-01T08:01:09Z

My vote goes for consistency with the iOS Runtime. The closer API-wise both Runtimes are, the better.

blagoev · 2016-07-01T08:03:49Z

ok thanks

@Pip3r4o ignore this suggestion

slavchev · 2016-07-01T08:04:02Z

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.

atanasovg · 2016-07-01T08:14:00Z

Btw, @Pip3r4o, it is [protocols] in iOS - in other words what's natural for the language. With that in mind - what @blagoev suggests seems more natural for Java - implements

petekanev · 2016-07-01T08:20:20Z

Must have remembered it wrong. Then yes, @blagoev's suggestion makes sense
too

On Friday, 1 July 2016, Georgi Atanasov notifications@github.com wrote:

Btw, @Pip3r4o https://github.com/Pip3r4o, it is [protocols] in iOS
http://docs.nativescript.org/runtimes/ios/how-to/ObjC-Subclassing#calling-base-methods-Protocol

in other words what's natural for the language. With that in mind - what
@blagoev https://github.com/blagoev suggests seems more natural for
Java - implements

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#501 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AJ-u2rxsGyZdZAc3VeRL2TJfzMHVF8_Eks5qRMxKgaJpZM4I_YRy
.

Sincerely,
Pete.

slavchev · 2016-07-01T08:22:57Z

In past we had some concerns about extends which is a keyword in JavaScript. I didn't fully understand them but I would like to point that implements is also a (reserved) keyword.

blagoev · 2016-07-01T08:36:27Z

One note on the suggestion:
How do we support this in typescript.
Our current approach of analyzing javascript code and __extend patching is working since it redirects the call the to appropriate A.B.C.extend() call which is the {N} JavaScript syntax.

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
{
interfaces: []
.... or this
static interfaces = [CallbackHandler];
public myMethod()
}

which results in JavaScript
MyActivity.interfaces = [CallbackHandler]; when static
or
this.interfaces = [CallbackHandler] when instance member

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)
class MyActivity implements CallbackHandler
{
}

or there is some other idea to support the proposed syntax from TypeScript

blagoev · 2016-07-01T08:40:22Z

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

blagoev · 2016-07-01T08:47:32Z

@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"

blagoev · 2016-07-01T09:11:21Z

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)
class MyActivity implements CallbackHandler
{
}

petekanev · 2016-07-01T11:15:07Z

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.

Plamen5kov · 2016-07-04T05:15:17Z

run CI

dtopuzov · 2016-07-04T07:28:16Z

run ci

ns-bot · 2016-07-04T10:27:23Z

💔

petekanev · 2016-07-04T13:34:47Z

run ci

ns-bot · 2016-07-04T13:38:55Z

💚

ns-bot · 2016-07-07T09:55:22Z

💚

petekanev · 2016-07-08T06:11:14Z

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 interfaces, because implements is a keyword. The property/decorator name can be discussed further, and changed, if deemed necessary.

slavchev · 2016-07-08T06:40:31Z

👍

Plamen5kov · 2016-07-08T06:46:30Z

👍

ns-bot · 2016-07-08T11:47:08Z

💔

ns-bot · 2016-07-08T12:11:08Z

💚

ns-bot · 2016-07-11T07:02:22Z

💚

…ple interfaces

ns-bot · 2016-07-21T09:14:34Z

💔

ns-bot · 2016-07-21T11:17:11Z

💚

petekanev added the feature label Jun 27, 2016

Plamen5kov changed the title ~~Classes can implemented multiple interfaces~~ Classes can implement multiple interfaces Jun 28, 2016

petekanev force-pushed the pete/feature-implement-interfaces branch from 87e579e to 68a7155 Compare July 7, 2016 07:46

petekanev force-pushed the pete/feature-implement-interfaces branch from e5519f0 to 0f8bc97 Compare July 11, 2016 06:58

petekanev added 8 commits July 21, 2016 11:57

runtime binding generator can now generate classes implementing multi…

ea5ec9f

…ple interfaces

small refactor job

78f142b

fix indentation

2f95f2b

move replaceAll string util method to Util

20f0fdb

add Interfaces decorator syntax support in ts_helpers

4a0ec65

add runtime binding generator for the new feature

aaf3dd0

fix failing test

17d3e8a

add updated ts_helpers to project-template

ead0e8b

petekanev force-pushed the pete/feature-implement-interfaces branch from 0f8bc97 to ead0e8b Compare July 21, 2016 09:08

fix bug

1be4f57

petekanev added this to the 2.2.0 milestone Jul 21, 2016

petekanev merged commit 7000a54 into master Jul 21, 2016

petekanev deleted the pete/feature-implement-interfaces branch July 22, 2016 05:35

petekanev mentioned this pull request Jul 22, 2016

2.0 NativeScriptActivity.java and NativeScriptApplication.java changes #442

Closed

NathanWalker mentioned this pull request Aug 8, 2016

Attempt to invoke virtual method 'java.lang.String java.lang.Package.getName()' - from Retrofit generating implementations from interfaces #528

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Classes can implement multiple interfaces #501

Classes can implement multiple interfaces #501

petekanev commented Jun 27, 2016 •

edited

Loading

ns-bot commented Jun 27, 2016

Plamen5kov commented Jun 28, 2016

blagoev commented Jul 1, 2016 •

edited

Loading

ns-bot commented Jul 1, 2016

vchimev commented Jul 1, 2016

ns-bot commented Jul 1, 2016

slavchev commented Jul 1, 2016

blagoev commented Jul 1, 2016

petekanev commented Jul 1, 2016

atanasovg commented Jul 1, 2016

blagoev commented Jul 1, 2016

slavchev commented Jul 1, 2016

atanasovg commented Jul 1, 2016

petekanev commented Jul 1, 2016

slavchev commented Jul 1, 2016 •

edited

Loading

blagoev commented Jul 1, 2016 •

edited

Loading

blagoev commented Jul 1, 2016

blagoev commented Jul 1, 2016

blagoev commented Jul 1, 2016

petekanev commented Jul 1, 2016

Plamen5kov commented Jul 4, 2016

dtopuzov commented Jul 4, 2016

ns-bot commented Jul 4, 2016

petekanev commented Jul 4, 2016

ns-bot commented Jul 4, 2016

ns-bot commented Jul 7, 2016

petekanev commented Jul 8, 2016

slavchev commented Jul 8, 2016

Plamen5kov commented Jul 8, 2016

ns-bot commented Jul 8, 2016

ns-bot commented Jul 8, 2016

ns-bot commented Jul 11, 2016

ns-bot commented Jul 21, 2016

ns-bot commented Jul 21, 2016

Classes can implement multiple interfaces #501

Classes can implement multiple interfaces #501

Conversation

petekanev commented Jun 27, 2016 • edited Loading

Description

Notable changes in files

Does your commit message include the wording below to reference a specific issue in this repo?

Related Pull Requests

Does your pull request have [unit tests]?

ns-bot commented Jun 27, 2016

Plamen5kov commented Jun 28, 2016

blagoev commented Jul 1, 2016 • edited Loading

ns-bot commented Jul 1, 2016

vchimev commented Jul 1, 2016

ns-bot commented Jul 1, 2016

slavchev commented Jul 1, 2016

blagoev commented Jul 1, 2016

petekanev commented Jul 1, 2016

atanasovg commented Jul 1, 2016

blagoev commented Jul 1, 2016

slavchev commented Jul 1, 2016

atanasovg commented Jul 1, 2016

petekanev commented Jul 1, 2016

slavchev commented Jul 1, 2016 • edited Loading

blagoev commented Jul 1, 2016 • edited Loading

blagoev commented Jul 1, 2016

blagoev commented Jul 1, 2016

blagoev commented Jul 1, 2016

petekanev commented Jul 1, 2016

Plamen5kov commented Jul 4, 2016

dtopuzov commented Jul 4, 2016

ns-bot commented Jul 4, 2016

petekanev commented Jul 4, 2016

ns-bot commented Jul 4, 2016

ns-bot commented Jul 7, 2016

petekanev commented Jul 8, 2016

slavchev commented Jul 8, 2016

Plamen5kov commented Jul 8, 2016

ns-bot commented Jul 8, 2016

ns-bot commented Jul 8, 2016

ns-bot commented Jul 11, 2016

ns-bot commented Jul 21, 2016

ns-bot commented Jul 21, 2016

petekanev commented Jun 27, 2016 •

edited

Loading

blagoev commented Jul 1, 2016 •

edited

Loading

slavchev commented Jul 1, 2016 •

edited

Loading

blagoev commented Jul 1, 2016 •

edited

Loading