Another discussion :grin: If you are in a situatio...

# announcements

[Rainer Schlonvoigt]

Another discussion 😁
If you are in a situation where both
Set<T> and List<T> are an option, which do you default to and why?

[Rainer Schlonvoigt]

I personally always go for List because if i don’t care about duplicates then the extra duplicates check seems a big waste

[Rainer Schlonvoigt]

but my Architect wants me to default to Sets everywhere

[christophsturm]

if its a set use a set and if its a list use a list 🙂

[christophsturm]

don’t use a set because you don’t need to store duplicates now.

[Matteo Mirk]

then your architect has a half-hidden requirement that needs to be better explicited. I would start asking him why he wants to use sets in the first place. Then, if there is the possibility to switch between the two, I would declare Collection in the interested API, so that it would accept/produce both without code changes and the preference would be a matter of requirement about duplicates or not, and/or performance; but those decisions can be made down the line, without breaking the API

[Rainer Schlonvoigt]

very nice solution, thank you 🙂

[Matteo Mirk]

Basically the public or topmost API of this part would declare Collection, and the private or inner functions can use Set or List as they prefer.

[christophsturm]

but thats only valid for return values. for parameter values you should declare them as the same types you test your code with. don’t declare a parameter as collection if you depend on the ordering

[Marc Knaup]

List and Set have quite different meanings so it’s unlikely that both are equally an option. What’s the use case?

I usually do that:
1. List if the order is relevant (in and out)
2. Set if elements really must be unique (in and out, elements are typically simple)
3. Collection if neither order nor uniqueness are relevant (in and out)