Open kirillzh opened 2 years ago
I don't know how to do this in general, since which functions need override
is language-specific. However, a to_string
method is very common and it could be nice to support. I think this would mean:
to_string()
@kirillzh Is there any situation in which toString
wouldn't need an associated override
in Kotlin?
If not, then @bendk, would you accept a PR that adds that behaviour to the Kotlin binding templates?
It would be akin to the existing code to do fixups for things like reserved words.
There are only three methods on Kotlin's Any
interface:
I strongly suspect that toString
is the only reasonable method for an FFI definition to override.
(Potential) Implementation notes
CodeOracle
, perhaps something like fn_name_on_base_class
kotlin
will use it, python
and swift
won't, ruby
could but overriding methods is painless in it.fn_name_on_base
to add an override
as appropriate in:
I don't have a strong opinion here, but have some contradictory thoughts:
toString()
magically special) because that's not the right thing to do for other languages. Eg, Python would want the same method to be named __str__
- if we really want to allow "this is a special method that gives a string repr of the object", it should be possible to do that in a consistent way regardless of the binding language.hashCode
and equals
should be ignored. @bendk and I have been chatting about allowing interfaces to be "traits", and such interfaces could be implemented either in Rust or in bindings - so Rust would be able to hold pointers to interfaces implemented in any or all languages. A logical (future, complicated) extension to this might be to allow a uniffi-based project to hold a hashmap of such interfaces. (To be clear, I don't think this is likely, but pushing uniffi's edge-cases is becoming an art form for some projects :) IOW, like the above point, a function who's intent is "do these objects compare equal?" should be something that generated override equals
for Kotlin and def __eq__(...)
in Python.It would be akin to the existing code to do fixups for things like reserved words.
to_string()
method, will trying to use Kotlin cause unexpected behaviour if the to_string()
in the UDL is not appropriate for toString()
on Any
? To put it another way, would a better option be to just rename this in the kotlin binding to, say _toString()
or similar?tl;dr, my opinion is best summarized as:
[Eq]
means the actual function name is ignored; Kotlin generate equals
, while Python generates __eq__
, etc)
Consider this UDL interface:
This generates Kotlin code that does not compile because
toString()
function is missing anoverride
modifier since this is an open, member function declared in theAny
class, which all classes implement in Kotlin:Correct way to fix generated Kotlin code is to add missing
override
modifier:As far as I can tell, uniffi doesn't currently provide a way to generate
override
modifier. Would it be reasonable to add support for it, perhaps, with an UDL syntax like this?Here's a real use case for this problem: https://github.com/bitcoindevkit/bdk-ffi/pull/154/files#r907940746. Meanwhile, an alternative workaround here is to use different API naming.
┆Issue is synchronized with this Jira Task ┆friendlyId: UNIFFI-177