Optional parameters about rspotify HOT 4 CLOSED

I don't like option E, because if the user wants to call an endpoint that doesn't require the market parameter at best they'll have to choose a random dummy value (which adds unnecessary extra code) and at worst they'll get confused and spend time getting a proper value.

I think that approach F is too complex. Even if we had macros that made it easy to implement, it basically doubles the size of the library, it's not worth it.

Approach G is too limited; it doesn't allow for users to have different markets for different queries. We don't want to force the user to have multiple clients, ever.

Between options A and B I don't have a preference, they both work. I don't think it matters which one is chosen.

PS: what happened to options C and D?

from rspotify.

Ooh, the letters came from your blog post. I didn't realize that and got really confused why two letters were skipped :P.

from rspotify.

The thing with E is that if the endpoint doesn't need the parameter it doesn't have to be specified. Its value will only be used for endpoints that require it. But yeah, I'm skeptical about it as well.

C and D seemed too basic to me and not exactly what we want. Of course, they can also be discussed. The main issue is that we'd need to declare both a function and a struct, and the user would have to import both of them as well, and with so many endpoints and so little of them with the exact same parameters I'm not sure if it's the most appropiate choice.

from rspotify.

After working a bit on #201 and working with function signatures, I've come to the conclusion that using so many unnecessary generic parameters with Into<Option<T>> is a mess. If anything I'd go for the simplest; option A.

Once #201 is done we'll get rid of the majority of optional parameters anyway, since when using iterators limit or offset don't need to be passed, so this should be less of a problem. The wonderful part about iterators is that the user can just use .take() or .take_while(), which won't cause unnecessary requests and can work as a limit.

from rspotify.