Skip to content
This repository has been archived by the owner on Aug 24, 2022. It is now read-only.

Proposal: QualifiedMethods #991

Open
iskiselev opened this issue May 31, 2016 · 4 comments
Open

Proposal: QualifiedMethods #991

iskiselev opened this issue May 31, 2016 · 4 comments

Comments

@iskiselev
Copy link
Member

iskiselev commented May 31, 2016

Based on my work on #988 and thoughts on #185, #623 I'd like to propose next:
Let's introduce QualifiedMethod. Qaulified method will

  • store type reference and method name. It may also contain method signature
  • extend function so on call will invoke target method either through signature or runtime dispatcher:
    • for instance method will accept this reference and return function, that
    • for generic methods will accept generic arguments and return function, that
    • will accept method arguments and call target method
  • have Call method, that will accept this reference, generic argumetns and method arguments in single call for perfomance-optimised calls
  • have Of method, that will accept same arguments, as MethodSignature and return QualifiedMethod with stored MethodSignature.
  • be stored in type public interface for static methods (same as now stored static method invocators, but they will be fully compatible) and inside $InstanceMethod property of type public interface for instance method (here they will replace InterfaceMethods that currently stored in type public interface). EDITED: If there is no overrides for method in type, it will store method signature, otherwise not.

Such organisation will allow us later solve #185, #623, #990 and provide statically-typed way to call any method with specified signature from TypeScript code.

@kg
Copy link
Member

kg commented May 31, 2016

This sounds fine design-wise, but I'd be concerned about the performance implications. Any thoughts on how we can minimize how many layers of function calls it adds and cut down on any indirection?

@iskiselev
Copy link
Member Author

Such method in initial implementation may add only one additional layer to normall call through signature (and will not add anything if compare with call through InterfaceMethod). Direct call of such objects will be nearlt same as current method call without signature.

Really, it may even give us some benefits - if we change our method signature caching algorithms to always use them with in-function caching, our function invocation cache will be always (except variance interface calls) switch with one case and created after first method call.

@iskiselev
Copy link
Member Author

iskiselev commented May 31, 2016

I'll do some benchmarks to understand better if it affects call perfomance.

@iskiselev
Copy link
Member Author

I've implemented extended InterfaceMethod to work with all non-static functions (static will add later). Each type now holds InterfaceMethods for each instance method. Using them to call methods add no overhead comparing to calling method through signature - and even have some benefits, as each InterfaceMethod correspond with only one method overload. So, we don't need use inline cache anymore for all except variance calls.
With it I was able to solve #185, #623 (so InheritedAndNewMethod and VirtualAndNewMethods tests are not broken anymore).
But it come with price: we should use signature call a little bit oftener and class initialization takes longer time (have not measured how much).

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

No branches or pull requests

2 participants