Add 'Any' type for JSON serializable types #131
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Originated from this PR #130
We have needs for a general "any" type. The intent here is to create a solution which is compatible both in a pure rust development environment but also in a UniFFI binding project.
There is a question of: "should we place this in
bindings/uniffi
instead? because it seems to be a constraint specific to UniFFI"The problem is on this line in
web5.udl
From @decentralgabe's comment here:
I have had a stretch goal of limiting the burden on layer (2) to solely associated functions because leveraging the
constructor
feature in UDL means the binded language can do a traditionalVerifiableCredential(...params)
. But in order for us to leverage theconstructor
feature, thecrates/credentials/src/vc.rs
would have to inline theAny
type in it's code. And ifAny
lives inbindings/uniffi
crate then that means our core crate now has a dependency on the UniFFI bindings crate. Which is no bueno.All of this to say, bindings really turns us into a pretzel. This PR is intended to spur discovery, we may choose to decline merging this. We need to establish patterns which are repeatable.