Derek Peirce
02/26/2022, 4:27 AMapplyMutation({ x }, { x = it })
I would much rather be able to pass in the property to the inline method, and have the getter and setter be derived from it automatically when inlining:
applyMutation(::x)
but we currently instead end up with terribly inefficient (compared to direct accesses) `KMutableProperty0`s.jw
02/26/2022, 4:29 AMx::get
and x::set
which would produce the two lambdas from the first snippet automatically.Derek Peirce
02/26/2022, 4:44 AMx::get
and x::set
would certainly be useful. For the property, I'd effectively hope that as the method is inlined, it would note that because the property was ::x
, a call to get
becomes x
, and a call to set
becomes x =
., and in the end the property object isn't involved at all, similar to lambda objects. It would also be nice if it could inline enough that something like javaField.name
to be known at compilation-time as "x"
, though that would probably have to be added to the KProperty
interface directly to be reasonably inline-able. (Ideally, it would eventually be powerful enough that methods like equals
and toString
could be derived entirely by the compiler even without data
.)ephemient
02/26/2022, 5:11 AMBenchmark Mode Cnt Score Error Units
ReflectionBench.javaReflection thrpt 5 163.525 ± 1.796 ops/s
ReflectionBench.kotlinReflection thrpt 5 555.280 ± 88.205 ops/s
ReflectionBench.methodHandle thrpt 5 135.869 ± 1.506 ops/s
ReflectionBench.noReflection thrpt 5 453.034 ± 10.804 ops/s
dmitriy.novozhilov
02/26/2022, 9:50 AMDerek Peirce
02/27/2022, 8:47 AMKProperty
in addition to creating a separate lookup library?dmitriy.novozhilov
02/27/2022, 9:29 AM