-
Notifications
You must be signed in to change notification settings - Fork 206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can the internal FFIConverter*
types be hidden?
#2030
Comments
We recently saw mls because it aligns with work we are planning to do and was quite excited to see uniffi used there, then saw your name attached to it and it all made sense :) In general, this sounds great. Some of these symbols probably do need to be "public" because they are referenced from other modules, but I'm fairly confident our test suite will cover all these cases - but they can probably be "hidden" (whatever that means for the specific binding in question). You mention sub-modules which might work well for some of the bindings - but yeah, we'd almost certainly take PRs for this. |
Nice! 😄 I'm excited too about this effort to bring more MLS to platforms like Android and iOS with the bindings created here!
Yeah, I don't think we can avoid exposing some parent classes here and there. In Android, we will eventually make the library available via Android Jetpack, and I understand that we have certain API guidelines for this. I'm not sure exactly what this means and if it restricts us in what we can leave public in the generated API. We have played with the idea of writing a shim API on top of the auto-generated API coming out of UniFFI — but it would of course be ideal to avoid this as much as possible to make maintenance reasonable.
Excellent! Then I'll start investigating what is possible and send some PRs to update the output. |
Hi all,
I'm using UniFFI with mls-rs and it's working well. The results so far can be seen in mls-rs-uniffi.
When generating Kotlin bindings, I notice a lot of helper types being generated. A small part of the documentation looks like this right now:
Of these,
Group
is a type I exposed, the rest are part of the UniFFI scaffolding. There are a few more such types (RustBuffer*
,NoPointer
,Uniffi*
, ...).Would it be possible to move these types to a sub-package or perhaps they could simply be marked package private or similar? I don't know exactly what mechanism is best for Kotlin, but anything which hides the classes from the documentation would be nice.
The same would of course apply to other target languages. The question is thus if this has been discussed in the past and if people would be open for patches that implement some form of hiding?
The text was updated successfully, but these errors were encountered: