Overload resolution ambiguity. All of these functions are the same

1

Hello. I’ve run into this problem: I’m trying
override the resourcesLoader method of the AVAssetResourceLoaderDelegate class of the native library
AVFoundation platform package.
First, this class is present in the package platform.
Instead, there is the AVAssetResourceLoaderDelegateProtocol class.
This class has 2 public methods with the same signature:

resourcesLoader(resourceLoader: platform.AVFoundation.AVAssetResourceLoader,
                            mustWaitForLoadingOfRequestedResource: AVAssetResourceLoadingRequest
): Boolean value


resourcesLoader(resourceLoader: platform.AVFoundation.AVAssetResourceLoader,
                            DidCancelLoadingRequest: AVAssetResourceLoadingRequest
): Unit

When trying to override, the IDE doesn’t understand which ones I’m trying to override.
(Overload resolution ambiguity. All of these functions are the same.)
How can I solve this problem?

1 Like
4

Thank you. Maybe I didn’t express myself correctly. I’m trying to override the platform.AVFoundation kotlin native library package methods in a kotlin mpp project.

5

Tbh I don’t think you can. Maybe there’s compiler options or something for Kotlin Multiplatform, but in Java (and I think other languages), methods/functions are unique based on their parameters (and name), NOT their return type. So two functions with the exact same name and parameters, but a different return type, are invalid; the compiler can’t tell the difference between the two functions. So I don’t think you’ll be able to override the functions; I’d be surprised if you’re even able to call them.

6

I never used Kotlin Native, so I won’t help with the problem, but I wanted to mention two things.

When I used the Objective-C in the past, I remember that in this language names of params are a part of the name of the method. I suspect Apple might do the same thing in Swift, especially because they use same libraries underneath. If this is true, then the name of these methods are not the same. They are not simply resourcesLoader, but more like: resourceLoader:mustWaitForLoadingOfRequestedResource: and resourceLoader:DidCancelLoadingRequest:. These methods don’t differ by the return type, but actually by the name. Maybe the bridge to Kotlin drops parameter names and if so, then this is actually a problem - we should be able to reference methods by their full name.

This is only partially true. Methods with exactly same name and param types, but different return type are disallowed in the Java source code, but they are allowed in the bytecode, they are supported by the JVM. Technically speaking, the return type is a part of the method descriptor and descriptor is how methods are identified in the bytecode. We can say internally method is identified by e.g.: foo(IZ)Ljava/lang/String;.

2 Likes
7

What? D: What’s even the point of that? So I can’t write source code, but I can use some kind of code generator that creates byte code to do it? That seems so useless. D:

8

I don’t think this was done on purpose. Compiler (source code) and JVM (bytecode) solve different kinds of problems. JVM has to be flexible, source code has to be clear, usable by humans and promote good practices. I suppose in the JVM/bytecode there is not even such a thing as method overloading - such methods are viewed as using entirely different “names”. Overloading is a purely source code concept.

4 Likes