Fill in README.md #12
Conversation
|
Could you also document what the limitations currently are, meaning what of dagger is not supported yet? |
|
If only I knew, I guess https://github.com/JakeWharton/dagger-reflect/search?q=notImplemented&unscoped_q=notImplemented is a good starting point (sadly it doesn't show all occurrences, only 1 for each file). I wouldn't put it in the README as a list though, just a link like above. @JakeWharton any thoughts on having a GH milestone with issues for each missing feature? |
Co-Authored-By: TWiStErRob <papp.robert.s@gmail.com>
|
@PaulWoitaschek added limitations. |
|
@JakeWharton is there any reason to not merge this? Do I need to do something here? |
|
I haven't read it yet. I assume it helps people use the library? I don't
want people using it yet.
…On Thu, Feb 14, 2019 at 3:26 PM Róbert Papp (TWiStErRob) < ***@***.***> wrote:
@JakeWharton <https://github.com/JakeWharton> is there any reason to not
merge this? Do I need to do something here?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#12 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEEEQHrHYNvhhvrJk99k6yckZxtm4WNks5vNcaOgaJpZM4agcdq>
.
|
|
Then merge it and add a disclaimer: "Do not use this". It's helpful for people taking a look at it and who are experimenting. |
|
I just said that I don't want you to and I have no interest in helping you do so at this time. |
| Er, what? Why would I want this? | ||
| -------------------------------- | ||
|
|
||
| Feels like going back to Dagger 1 by Square? Not quite: we keep the benefits of Dagger 2, including the annotation processing compile-time validation in production, but using reflection speeds up development builds. |
There was a problem hiding this comment.
Dagger 1 used code generation and compile-time validation. The only feature it didn't have compared Dagger 2 was... maps?
This project is more like Guice.
|
|
||
| * ProGuard/DexGuard/R8: since the dependency injection entry point (e.g. `@Component.Builder`) is being reflected with either usage case, you'll lose some shrinkability, but the majority of the generated `@Component` code using `@Module`s will be shrinked the same as before. | ||
|
|
||
| * `dagger-android`: it uses a lot of Dagger features, namingly: |
There was a problem hiding this comment.
Most of these are implementation details. I don't think it's our responsibility or useful to document all this.
| -keepclassmembers class ** implements @dagger.Component ** { | ||
| public static <2> create(); | ||
| } | ||
| ``` |
There was a problem hiding this comment.
These rules can be embedded in the jar to be picked up automatically and we can add test cases to ensure they work. They don't need to be documented anywhere.
| This is due to a limitation in Java, where instances of proxies cannot create another proxy instance where the second interface is not public. This prevents proxies of builders from creating proxies of the component. See `dagger.reflect.ComponentBuilderInvocationHandler.create`. | ||
|
|
||
| * There are some missing features that are not yet implemented. | ||
| They can be found by looking at [`notImplemented` calls in the code][notImplemented]. |
There was a problem hiding this comment.
There won't be any releases until these are all gone
Copied from butterknife-reflect as a baseline.
Added both usages, Kotlin to be done after it's implemented.
dagger-androidto be discoveredpreview available at https://github.com/TWiStErRob/dagger-reflect/tree/usage