Inner-Class Component Generated Code Naming

[google]

Inner-Class Component Generated Code Naming

[cgruber]

Dagger 2.0 has been released, and the names are, for @component Foo you get
DaggerFoo, and for @component Bar.Blah (nested) you get DaggerBar_Blah as
the implementation types for components.

On Mon, 13 Apr 2015 at 10:41 TJ (Thomas J.) Biddle [email protected]
wrote:

@cgruber https://github.com/cgruber Also - quick clarification. This
will also fix the issue regarding the prefixes having changed from the
2.0-SNAPSHOT? They used to be Dagger_xxxx And now it's just Daggerxxxx from
what I'm hearing

—
Reply to this email directly or view it on GitHub
#58 (comment).

[gk5885]

Yeah, that needs to be fixed. We are actually tracking a bug internally for this.

[codefromthecrypt]

+1 on the AutoValue style naming convention.

[gk5885]

Hey, while we're all chatting about it…

Dagger_MyComponent or DaggerMyComponent (or something else)

MyClass$$Factory or MyClass_Factory or MyClass__Factory (or something else)

[codefromthecrypt]

I'm pretty in favor of underscores. At slight checkstyle risk for the
overzealous, it avoids confusion about regular $ use.

[JakeWharton]

For generated code that needs to be explicitly referenced, I definitely prefer underscores. For generated code that's not referenced directly I'd leave it or keep it relatively clear that it's generated.

[cgruber]

I actually prefer underscores even for generated unreferenced code because
eclipse has serious problems with $. Given that all generated code is
viewable, people will step into code that will erroneously show errors.
Underscores seem to not invoke this bad editor behavior.

On Sat, Nov 8, 2014, 04:20 Jake Wharton [email protected] wrote:

For generated code that needs to be explicitly referenced, I definitely
prefer underscores. For generated code that's not referenced directly I'd
leave it or keep it relatively clear that it's generated.

—
Reply to this email directly or view it on GitHub
#58 (comment).

[JakeWharton]

Kotlin has problems with $ as well. Kill kill kill it.

[Ch3D]

+1
This issue stops me from migration to Kotlin

[Lakedaemon]

+1
I'm a kotlin developer. This issues stops me from migrating to dagger. :)

[artem-zinnatullin]

I am using Dagger 2 with Kotlin without any problems:

Components and Modules in Java, injecting like this (Android):

public class App extends Application {

    private DIGraph mDIGraph;

    /**
     * Returns application object from context
     * @param context to get application object
     * @return application object
     */
    public static App get(Context context) {
        return (App) context.getApplicationContext();
    }

    @Override public void onCreate() {
        super.onCreate();

        mDIGraph = Dagger_DIGraph.builder()
                // creating modules
                .build();
    }

    @NonNull public DIGraph getDIGraph() {
        return mDIGraph;
    }
}

class SomeFragment : Fragment {

    var someVar: SomeType? = null
        [Inject] set

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        App.get(getActivity()).getDIGraph().inject(this)

        // we can work with injected someVar
    }
}

[mboudraa]

+1

[asm0dey]

👍

[steindekker]

+1

[leomindez]

+1

[cgruber]

Dagger does Dagger_OuterClass_Foo for components. It will ultimately reject $$ for generated types, but this may not happen in time for 2.0. I'm marking this as a 2.1 issue.

[cgruber]

Fixed in #150