https://kotlinlang.org logo
#feed
Title
# feed
r

raulraja

04/17/2019, 9:31 AM
For those of you that were spectating regarding KEEP-87. We just submitted the proposal after getting a working prototype. KEEP-87 proposes compile time DI for Kotlin alongside extension interfaces. https://kotlinlang.slack.com/archives/C0B9K7EP2/p1555493024015100
👍 5
🤔 3
a

altavir

04/17/2019, 10:35 AM
You present a rather demonstrative case:
Copy code
fun <A> fetchById(id: Int, with repository: Repository<A>): A? {
  return loadById(id) 
}
But is does not seem to have a lot of added value on top of
Copy code
fun <A> Repository<A>.fetchById(id: Int): A? {
  return loadById(id) 
}
This variant requires explicit receiver in the function call-site, but on the other hand saves a lot of problems with possibly confusing dependency resolution.
👍 3
The proposal is much better than before though.
r

raulraja

04/17/2019, 3:24 PM
There is a difference, plain extension functions are limited to a single receiver
Extension interfaces are not constrained to a single receiver
a

altavir

04/17/2019, 3:25 PM
Multiple receivers could be done via KEEP-176 without any implicit logic.
Probably both will be done via compiler plugin sooner or later.
r

raulraja

04/17/2019, 4:28 PM
Extensions functions as they are today are effectively implicit arguments no matter what we call them. The compiler implicitly activates functions syntax over types when those functions may not be part or members of the type and passes values as arguments to functions to achieve the syntax. I think there is overlap with KEEP-176 and as we mentioned in the text we are not really married to any particular encoding. Whatever brings the abilities to group extensions for a type I think it'd be great and good for Kotlin.
a

altavir

04/17/2019, 4:33 PM
Extensions functions as they are today are effectively implicit arguments no matter what we call them.
No, they are not. Extension receivers are explicit in the call site. The main difference of your proposal from KEEP-176 is the implicit context resolution. KEEP-176 forces to explicitly define all receiver objects at the call site (while you try to infer them at use site).
4 Views