Comments (5)
See also https://github.com/mozilla/uniffi-rs/tree/main/fixtures/trait-methods
from uniffi-rs.
It should be possible for objects - https://mozilla.github.io/uniffi-rs/udl/interfaces.html#exposing-methods-from-standard-rust-traits. It's not possible for records because records have no methods (and it's not immediately obvious we should fix that, given every method call would involve moving the entire record over the FFI, then constructing an object on the rust side, then making the call, which would obviously be very expensive for very large records)
from uniffi-rs.
It should be possible for objects - https://mozilla.github.io/uniffi-rs/udl/interfaces.html#exposing-methods-from-standard-rust-traits.
Oh, thank you! I need to read the UDL section of the manual much more carefully 😄 I've been hoping to avoid it and just use the proc-macros. I see they support this too, so that's neat.
It's not possible for records because records have no methods (and it's not immediately obvious we should fix that, given every method call would involve moving the entire record over the FFI, then constructing an object on the rust side, then making the call, which would obviously be very expensive for very large records)
Very good point...
For the case of a derived Eq
, I guess one could deal with records by generating the same implementation in the target language — compare field by field. Eventually, this should bottom out in an object or in a primitive type. That should give all the nice properties one would expect: short-circuiting if two fields don't match, cheap since nothing is sent back to Rust.
One could do similar things for Debug
, Display
, and Hash
. In general, this would only be correct if people don't customize these implementations on the Rust side. That might suggest that
#[derive(Debug, uniffi::Object)]
#[uniffi::export(Debug)]
struct TodoList {
...
}
should be
#[derive(uniffi::Object)]
#[uniffi::derive_and_export(Debug)]
struct TodoList {
...
}
which would mean that UniFFI is fully responsible for deriving and exposing a standard Debug
implementation.
from uniffi-rs.
I can see how records might do this for eq. Display needs a Rust impl IIUC. For Debug, the subset of supported types is such that maybe we could think about generating this by default. Or maybe some way of flagging this as something described as, eg, a "simple" type which flags both eq and default get implemented by default? hash is unclear - would it be necessary in some future for everyone to agree on the hash algo?
from uniffi-rs.
Display needs a Rust impl IIUC
Good point! So the logic could be that UniFFI will emit an implementation in the target language for traits which can be derived in Rust. The implementation will do the same as the Rust implementation, but in the target language.
Traits like Display won't be in scope for this since they cannot be derived and so we don't have a default implementation to mimic in the target language.
hash is unclear - would it be necessary in some future for everyone to agree on the hash algo?
I haven't checked what deriving Hash does in Rust, but I imagine it just accumulates hash values for every field. So it should be easy to implement this in the target language.
I would like to try implementing this at some point — if/when we find that we need this.
from uniffi-rs.
Related Issues (20)
- Expose panic line numbers in logcat
- Kotlin bug: enum with associated value being `Arc<Object>` generates non compiling Kotlin code (UniFFI 0.27.1) HOT 1
- Clarify `check_library_path` semantics HOT 2
- DISCUSS: Proc macro / UDL for Swift property wrappers and macro annotations HOT 4
- Issues while importing and using a created swiftmodule HOT 5
- Incorrect comments in RustBuffer about being limited to i32
- how to send Rust opaque type to Kotlin HOT 5
- Online docs have no language syntax highlighting HOT 1
- RustBuffer regression with nested Errors HOT 5
- Swift errors don't provide `localizedDescription` HOT 6
- Generating FFI bindings for dependent crates into one single Swift / Kotlin file? HOT 4
- External type fails for some corner cases HOT 1
- Config feature and Export macros don't get along HOT 1
- iOS Framework Expected in: /usr/lib/libc++.1.dylib HOT 2
- Remote interface types
- Updating from 0.25.3 to 0.26.x or 0.27.x fails for interface HOT 8
- Java 8 deprecation is unexpected
- #[doc = ...] fails to parse with uniffi attribute macros HOT 1
- update docs/diplomat-and-macros.md
- Crates.io shows 0.27.2 but the associated tag doesn't exist HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from uniffi-rs.