Apparently doing this: ```@field: Named(value = "approvals")``` actually works. No clue what this s...

# getting-started

[Siegfried Kiermayer]

Apparently doing this:

@field: Named(value = "approvals")

actually works. No clue what this should do

[Roukanken]

afaik, an annotation like:

class FooBar {
    @Annotation
    some: Field;
}

is applied to property target by default, and that one is not visible to java at all

[ephemient]

https://kotlinlang.org/docs/annotations.html#annotation-use-site-targets
depends on whether the annotation was defined in Kotlin or Java, and what its declared targets are, but target in that position is the first applicable of param, property, or field if you don't tell it

[ephemient]

if you're using javax.inject.Named, that's a Java annotation so it can't be @property:Named, but since it doesn't have other restrictions it could be both @param:Named and @field:Named, so it defaults to the former

[ephemient]

you should almost certainly be using constructor injection though,

class FooBar @Inject constructor(
    @Named("approvals")
    private val approvalsProcess: Process<out Model>
) {

if you really need field injection, that's one of the cases for lateinit var, but val for something that will be mutated is not good

[Siegfried Kiermayer]

i'm slowly starting to get it. property vs. field is a weird differentiation i don't get as property vs. field is more a scope issue and property would be more visibile than a field.

But really really getting it, nope

[Siegfried Kiermayer]

this section doesn't explain too much about the ups and downs of constructor injection vs. the other either https://quarkus.io/guides/kotlin#cdi-inject-with-kotlin

[ephemient]

approvalsProcess translates into several different things:
• a parameter in the primary constructor
• a property, which is made of
◦ a getter, and
◦ a backing field
"property" isn't a concept in Java, so @property: can only be used by (and can only be seen by) Kotlin annotations, but @param: @get: @field: are otherwise possible there

[ephemient]

constructor injection means the dependencies are provided to the constructor. this is the ideal for Kotlin, since everything can stay immutable

[Siegfried Kiermayer]

so property as it is used in c# / simliar to in c#?

[ephemient]

field injection is sometimes required when dealing with certain frameworks (such as Android) where constructor injection isn't possible. it is a step after the constructor is called which changes the underlying fields. this should be denoted by lateinit var in Kotlin - var since they're definitely mutated, and lateinit which indicates to the compiler both that it isn't initialized in the constructor, and also the field should be exposed to Java/reflection

[Roukanken]

Yeah, properties are similar to C# ones,
you can even define them manually, example from docs:

class Example {
    var stringRepresentation: String
        get() = this.toString()
        set(value) {
            setDataFromString(value)
        }
}

[ephemient]

you can think of public properties as similar to C#, but they're not totally

[ephemient]

the Kotlin compiler will optimize a private property without custom getters/setters to just a field

[Siegfried Kiermayer]

interesting. that makes a few things much clearer. is there some book/guide on those mechanics / kotlin to java translations / behaviours?

[ephemient]

and the existence of a backing field is inferred by whether it would be needed or not, e.g.

var foo // has backing field
var foo // has backing field because it's mentioned
    get() { println("getting $field"); return field }
    set(value) { field = value }
var foo // has no backing field because it's not mentioned
    get() = 1
    set(value) { /* ignore */ }