# Member extension resolution **URL:** \ **Category:** Uncategorized\ **Created:** [May 21, 2020, 1:26pm UTC](https://discuss.kotlinlang.org/t/member-extension-resolution/17780 "2020-05-21T13:26:59Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![wdoker](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/wdoker/32/4748_2.png) [@wdoker](https://discuss.kotlinlang.org/u/wdoker)\ **Post date:** [May 21, 2020, 1:26pm UTC](https://discuss.kotlinlang.org/t/member-extension-resolution/17780/1 "2020-05-21T13:26:59Z")
seems a little strange to me: ``` open class A interface I { fun A.foo() } fun main() { val a = object : A(), I { override fun A.foo() = TODO() } a.foo() // error. foo is not resolved a.apply { foo() } // OK } ``` Is there any explanation? ---
**Author:** ![al3c](https://avatars.discourse-cdn.com/v4/letter/a/e47774/32.png) [@al3c](https://discuss.kotlinlang.org/u/al3c)\ **Post date:** [May 21, 2020, 1:45pm UTC](https://discuss.kotlinlang.org/t/member-extension-resolution/17780/2 "2020-05-21T13:45:18Z")
That’s a somewhat unusual scenario. My take is that `foo` is a function that can be called only when you have an `I` in scope, that is usually while you’re implementing methods of `I` itself. I can only infer that also an extension function on an instance of `I` can access that member (which seems useful for DSLs) ---
**Author:** ![lamba92](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/lamba92/32/5089_2.png) [@lamba92](https://discuss.kotlinlang.org/u/lamba92)\ **Post date:** [May 21, 2020, 2:09pm UTC](https://discuss.kotlinlang.org/t/member-extension-resolution/17780/3 "2020-05-21T14:09:41Z")
When creating an anonymous class with multiple ancestor types you need to specify the only type your object is! Otherwise create a class `B` exactly for that purpose: ```kotlin class B : A(), I ``` Let the object extend B and everything will work fine because `B` contains the notion of both `A` and `I`, while an anonymous object cannot (unless you cast, but when you do, you lose the other type!) ---
**Author:** ![wdoker](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/wdoker/32/4748_2.png) [@wdoker](https://discuss.kotlinlang.org/u/wdoker)\ **Post date:** [May 21, 2020, 2:26pm UTC](https://discuss.kotlinlang.org/t/member-extension-resolution/17780/4 "2020-05-21T14:26:55Z")
You mean this? ``` open class A interface I { fun A.foo() } open class B: A(), I { override fun A.foo() = TODO() } fun main() { (object : B() {}).foo() // error B().foo() // error } ``` It doesn’t work either ---
**Author:** ![darksnake](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/darksnake/32/2479_2.png) [@darksnake](https://discuss.kotlinlang.org/u/darksnake)\ **Post date:** [May 21, 2020, 3:18pm UTC](https://discuss.kotlinlang.org/t/member-extension-resolution/17780/5 "2020-05-21T15:18:39Z")
An interesting case. Your method `foo` actually has two receivers. A member receiver `I` and an extension receiver `A`. According to current rules, the function has two arguments, and when you provide only one (event if it satisfies both types) it is not recognized. When we were discussing KEEP-176, we proposed different rules, when one object could be recognized as multiple receiver types at once, but it requires a slight change of ideology. ---
**Author:** ![wdoker](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/wdoker/32/4748_2.png) [@wdoker](https://discuss.kotlinlang.org/u/wdoker)\ **Post date:** [May 21, 2020, 4:08pm UTC](https://discuss.kotlinlang.org/t/member-extension-resolution/17780/6 "2020-05-21T16:08:38Z")
BTW, is there any progress on compound extensions/typeclasses dillema? I thought typeclasses got the green light since @abreslav mentioned them in a public talk ---
**Author:** ![darksnake](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/darksnake/32/2479_2.png) [@darksnake](https://discuss.kotlinlang.org/u/darksnake)\ **Post date:** [May 21, 2020, 4:54pm UTC](https://discuss.kotlinlang.org/t/member-extension-resolution/17780/7 "2020-05-21T16:54:39Z")
Type-classes are not a solid concept, even KEEP-87 team stopped to use the term. Type classes are invented for haskel and are not quite useful as themselves in a language with inheritance. As for contextual extensions, we will see what route language community will take. Both KEEP-176 and KEEP-87 cover significant portion of use-cases, but the approach is different. ---
**Author:** ![Wasabi375](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/wasabi375/32/4741_2.png) [@Wasabi375](https://discuss.kotlinlang.org/u/Wasabi375)\ **Post date:** [May 21, 2020, 8:32pm UTC](https://discuss.kotlinlang.org/t/member-extension-resolution/17780/8 "2020-05-21T20:32:31Z")
> [@wdoker](#): > > BTW, is there any progress on compound extensions/typeclasses dillema? I thought typeclasses got the green light since @abreslav mentioned them in a public talk I must have missed that talk. Do you have a link or at least know when this talk was? ---
**Author:** ![wdoker](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/wdoker/32/4748_2.png) [@wdoker](https://discuss.kotlinlang.org/u/wdoker)\ **Post date:** [May 22, 2020, 6:32am UTC](https://discuss.kotlinlang.org/t/member-extension-resolution/17780/9 "2020-05-22T06:32:54Z")
Unfortunately, I completely forgot where it was. All I remember is that it was in russian. ---
**Author:** ![darksnake](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/darksnake/32/2479_2.png) [@darksnake](https://discuss.kotlinlang.org/u/darksnake)\ **Post date:** [May 22, 2020, 6:57am UTC](https://discuss.kotlinlang.org/t/member-extension-resolution/17780/10 "2020-05-22T06:57:01Z")
As far as I remember, he mentioned them on the closing panel on the kotlinconf-2019. But as I already said, type-classes is a general concept that could not ( and should not) be ported to Kotlin as is. There are different ways to achieve the same functionality. File-level receivers I mentioned in KEEP-176 discussion, provide quite similar functionality without introducing implicit lookup table. I think that everybody want some kind of contextual behavior abstraction, but I do not think that there is a clear path to it.