Library api design - filtering/sorting/etc Vecs

Hey I'm new and just wondering how yall would normally do something.
I have a small library. It returns to the caller, basically, a vec of structs.

There are some common filtering sorting things you'd want to do. Should I make methods for those, or just let the user figure it out. It's like filter by .name, sort by .metric, get item with lowest .metric, stuff like that.

Alternatively the user could just do my_vec.into_iter().filter.sort() type stuff right?

Mostly looking for articles or the right search words to search for. Or some small repos to look at.

the api right now is looking like a

.list() -> Result <Vec<T>, Error>
.find_by_name(str) -> Result <Vec<T>, Error>, 
.get_by_id(id) -> Result <T, Error>

type of thing.

Maybe there's a performance or borrowing or typesafety or friendlyness benefit to doing some of the operations in the library? I don't know yet!

1 Like

This heavily depends on how you get the results, how many results there are, etc. So it's not possible to give a definite answer, only a conditional one.

Generally, standard library types have excellent support for iteration and sorting (where applicable), and you should not try to replicate these methods yourself in the interest of avoiding re-inventing the wheel and introducing bugs. Just give the user an iterator, and they can collect it into whatever collection they need, and even filter it or map it to some other type beforehand.

However, if there is a real benefit, you might consider including especially filtering operations. For example, do you retrieve your results from a database or a network API? If so, then you can potentially spare a lot of memory and runtime by not retrieving every record ever and then filtering in-memory. So if you are querying an API or a DB, then by all means perform possible filtering and projections instead of just loading everything into memory.

Which of these two scenarios fits your use case more?

5 Likes

Good question! Thanks. I'm getting the data from an api I don't control, and it doesn't have filter.
It's always "small". Less than 10 items most of the time, and almost never 100 items. It's the network adapters on Windows.

Interesting about returning an iterator instead of a vec.

In this case, don't bother duplicating the functionality of iterators, just return an iterator or a collection and let the users perform any anticipated filtering.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.