You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
From #15:
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
i.e. fail silently rather than forcing the user to remove/disable DevFun completely (this is a must)
Determine the feasibility of generating Dagger 2.x injection stubs that would create a proper graph for us at compile time.
final
modifier - in a similar fashion it might be nice if we either:The text was updated successfully, but these errors were encountered: