Implement derive macro to automatically convert Value to T

[sheepduke]

Automatically implement From<StructValue> for T with derive macro.

[gruebel]

hey @sheepduke could you share more details for this task, I would be interested to contribute, but not sure what exactly is asked for 😅

[sheepduke]

hey @sheepduke could you share more details for this task, I would be interested to contribute, but not sure what exactly is asked for 😅

@gruebel Sure! You see, we have a function get_struct_value defined in the client.rs file. It is used to return a structure as required by the specification. The caller is able to pass in a type parameter T and this function will return corresponding type, as long as T implements TryFrom<StructValue>. Here StructValue is a variant of enum Value that we use to represent the structure internally, similar to how serde_json handles this.

Now to really make use of this function, the caller needs to manually implement TryFrom<StructValue> for their custom type, unless they just want StructValue. This is not convenient, if ever useful.

My idea is to implement something similar to serde. The consumer can simply derive something when defining their custom types, and the corresponding impl TryFrom<StructValue> and/or impl TryFrom<&StructValue> code is automatically generated.

Further more, you may have noticed that there is a feature serde_json that implements TryFrom<serde_json::Value> and TryFrom<&serde_json::Value> for our own Value. We may add another feature serde that generate corresponding code for type T when T derives serde. So, the consumer can simply enable this feature and all the custom types that have serde serialization defined can automatically supported like get_struct_value<MyType>.

These are just my brief ideas. Please feel free to ask any question and/or propose your ideas here. :-)

[gruebel]

Thanks, definitely will give it a try 💪

[gruebel]

hey @sheepduke I finally had some time to look into it and as far as I understand it, we would need to create a separate crate to implement a procedural macro. If we want to go that way, we should first change the project to leverage a workspace and then create a new package open-feature-derive. WDYT?

[sheepduke]

hey @sheepduke I finally had some time to look into it and as far as I understand it, we would need to create a separate crate to implement a procedural macro. If we want to go that way, we should first change the project to leverage a workspace and then create a new package open-feature-derive. WDYT?

Strange. I thought I replied your message via email but it seemed not. My bad. :-(

I am absolutely fine with it, especially when there is not another choice...