Skip to content
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

Investigate Kotlin Compiler plugin for generating/handling default value arguments (and injection?) #17

Open
alex2069 opened this issue Feb 9, 2018 · 0 comments
Assignees

Comments

@alex2069
Copy link
Contributor

alex2069 commented Feb 9, 2018

From #15:

Desirable

  • Kotlin default values should be filled automatically
    • Unfortunately the default parameter values are neither provided during annotation processing or kept in the class file (i.e. as metadata).
      Functions with default arguments result in a synthetic bridge function where the default values are kept in the body of the function. Invocation of the function uses a bit field determined at compile time to know which default arguments are needed. A call is then made to the original function with all the values.
      A compile plugin or additions to KAPT will be required to implement this feature.

This would be nice to look into, however the plugin API isn't "official" per se. It exists as a "plugin API", though is only really used internally and not well documented.
While there are a number of implementations suggesting some level of maturity (all-open, no-args, android-extensions, android-parcelable, and possibly more), there could be stability issues that may cause DevFun to become unusable.

Tasks

  • Determine how stable/mature the API is.
  • Determine if DevFun can continue to function with compiler API changes.
    i.e. fail silently rather than forcing the user to remove/disable DevFun completely (this is a must)
  • Currently we only support simple Dagger 2.x graphs via. reflection.
    Determine the feasibility of generating Dagger 2.x injection stubs that would create a proper graph for us at compile time.
  • The all-open plugin remove the final modifier - in a similar fashion it might be nice if we either:
    • Make annotated functions/classes as public/internal (allowing direct invocation rather than sourcing the reference via. reflection. (probably not this - it may have issues with overrides etc)
    • Generate a synthetic bridge method to call it for us. (this is what's done for inner private methods in the Java world, so seems like a safe bet)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant