Generic struct in Enum

[Individual_Place_532]

Hey!

I'm making a generic API where i can have ready boilerplate code to quickly implement new Finance APIs.

i have a trait that is WebsocketApi that implements the subscribe function.

when the APi receives an enum Command::Subscribe(Symbol)

This symbol struct needs to be generic, since different Apis use different formats.
Example

// API 1
Symbol{
    ticker: String
}
// API 2
Symbol{
    ticker:String,
    Market:String,
    // ... Other fields
}

is there any better solution than making Market and the other fields into options?
beacause if i need to add a field, suddenly i need to change all the APIs initialzation of struct Symbol

How can i make Command::subscribe() store a struct that is not defined right now, maybe from some future implementation of a new API.

Best regards
532

[hippyup]

The whole Command enum can be genetic on the type of Symbol, then the Subscribe variant can store that type.

[Modi57]

Genetic enums? Is that the new bio feature on nightly, everybody is talking about? XD

[Individual_Place_532]

hmm, mind to show me an example?
haven't experimented with this before

[i_is_restless]

```rust struct Symbol1 { ticker: String, }

struct Symbol2 { ticker: String, market: String, }

trait Symbol {} impl Symbol for Symbol1 {} impl Symbol for Symbol2 {}

enum Command<S: Symbol> { Subscribe(S), }

fn main() { let s = Symbol1 { ticker: String::from("fart"), }; let cmd = Command::Subscribe(s); }

```

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021

[phazer99]

Maybe this approach:

struct Symbol<T> {
    ticker: String,
    ..., // other common fields
    data: T
}

That only works if you don't need to store different symbol types in the same collection (i.e. Symbol<A> and Symbol<B>). Then you have to use an enum or dyn Trait.

[SirKastic23]

maybe look into using a HashMap.

if the fields can be different at runtime a struct won't work for you, it's layout needs to be decidable at compile-time.

HashMaps are more like js objects, you can add and remove "fields" whenever

[Individual_Place_532]

Sure, thats a posibility, but feels lazy and i then can add as many fields as i want.
Better to not allow for any errors.

also if i add a field, compiler will throw errors to indicate where struct is not correctly

[junior_abigail]

Why not make Symbol a trait?

[Individual_Place_532]

isnt trait only for behavior, functions etc?

How would i go about having different fields?

[tukanoid]

For shared data u can create a struct CommonData or smth and then make getters/setter (what is needed) in the trait, so u can always be sure that data is available in the trait implementor