Call protocol methods on private classes

[jasssonpet]

Consider the following case:

@protocol MyProtocol1<NSObject>
- (void)method1;
@end

@protocol MyProtocol2<NSObject>
- (void)method2;
@end

@interface MyClass : NSObject
+ (id<MyProtocol1, MyProtocol2>)getObject;
@end

There should be a non-hacky way to call method1/method2 on the object returned by MyClass.getObject().

This is required by the NativeScript modules for custom page transitions.

ping @hamorphis @PanayotCankov

• [x] Attach prototypes to protocol wrappers
• [ ] Make calling protocol methods on objects of type SomeInterface<Protocol1, Protocol2> more natural:

MyClass.getObject().method1(...);

instead of

MyProtocol1.prototype.method1.call(instance, ...);

by including prototypes of the implemented protocols in the inheritance chain. This way instanceof will work for protocols, too.

[PanayotCankov]

I'd suggest that we create constructor functions and wire properly the inheritance chain for these private classes at runtime. These runtime created classes should expose the methods from any known public protocols implemented by the private Obj-C class. Then we should be able to wrap the private instances so we can easily call from JavaScript the methods conforming to the protocols, just as we can from Objective-C or Swift.

[ivanbuhov]

@PanayotCankov I agree that your solution leads to more naturally calling protocol methods, and instead of writing

MyProtocol1.prototype.method1.call(instance, ...);

you will be able to achieve the same with

instance.method1(...);

However, your solution is not contrary to the currently implemented one. If we take your approach we still have to attach protocol prototypes to their corresponding constructor functions, because IMO its quite natural and also this will make instanceof to work with protocols, too. However, this PR has value on its own because it allows you to call methods from protocols listed in <...> which was not possible till now (without using some hacky workarounds), and gives us the possibility to make it more elegant in the future.

[fealebenpae]

@PanayotCankov @ivanbuhov We can't rely on Objective-C introspection to provide reliable information on what protocols a class conforms to. The most recent example is UIViewControllerContextTransitioning - this protocol isn't even registered with Objective-C at runtime, so there is no way for us to query whether or not an instance of a private class conforms to it, even though the private class does actually conform to it by implementing all methods from the protocol.