Update dis_macro and add ref dis injection

[garethj2]

Two changes here...

1. dis_macro: now returns a Cow for the get_value function passed into it. This gives more flexibility when using the API. Please note, no version has been published since this last change so it can't be considered a breaking change.
2. ref dis injection: I needed someone to inject Ref display name values into decoded objects. This is required in a haystack server when one is dynamically calculating a record's display value and needs to share it with all record's in the database in an efficient manner. I admit I'm not 100% happy with this. I couldn't find a nice efficient way to do some sort of configuration injection into a Serde deserializer. Regardless, I've isolated this to a specific part of the library so it doesn't pollute the core Ref value type. I think this really could be enhanced further by making the core API able to share references more easily and hence use proper interning for granular haystack data types.

[garethj2]

Would appreciate your thoughts on this @rracariu . I just want to make sure you're happy with my ref display name injection addition.

[rracariu]

I would go with a trait that implements the generic approach in the library, and then re-implement this trait in another crate using the new-type pattern, see Using the Newtype Pattern to Implement External Traits on External Types
IMHO this would make this less fragile and most likely more performant as there are less indirections and lock access, in exchange of a little more coding effort in the consumer crate.

To summarize: crate a trait for this macro facility, implement it for Value and Ref in this library crate, use this default implementation for the ser/de, then in another crate that depends on this library, create wrappers for Value and Ref (List, Dict, Grid?) implement the dis macro trait for these wrappers and partially implement the Serde traits for serialize/deserialize parts where you do your specialization for whatever use case you have, and delegate the rest to the default Value and Ref types. Create wrappers for zinc if this is the case.

If you want, you could completely circumvent the library type crate and only use the wrappers in the consuming crate by using transparent references via the Deref polymorphism
I don't think this would be need it, as probably you only need this facility of ser/de parts, so in this case those wrapper structs would suffice.

[garethj2]

I would go with a trait that implements the generic approach in the library, and then re-implement this trait in another crate using the new-type pattern, see Using the Newtype Pattern to Implement External Traits on External Types IMHO this would make this less fragile and most likely more performant as there are less indirections and lock access, in exchange of a little more coding effort in the consumer crate.

To summarize: crate a trait for this macro facility, implement it for Value and Ref in this library crate, use this default implementation for the ser/de, then in another crate that depends on this library, create wrappers for Value and Ref (List, Dict, Grid?) implement the dis macro trait for these wrappers and partially implement the Serde traits for serialize/deserialize parts where you do your specialization for whatever use case you have, and delegate the rest to the default Value and Ref types. Create wrappers for zinc if this is the case.

If you want, you could completely circumvent the library type crate and only use the wrappers in the consuming crate by using transparent references via the Deref polymorphism I don't think this would be need it, as probably you only need this facility of ser/de parts, so in this case those wrapper structs would suffice.

Thanks for the great advice @rracariu . I've implemented this and it works very nicely! I've removed the ref display name injection from the code base. I did make the serde visitor decoder public so I could reuse when I create my own serde decoder visitor. I agree this is a far better approach for now. It keeps this library nice and clean.

[rracariu]

LGTM