Replies: 1 comment · 1 reply
-
|
I agree, that many lists could be sets, e.g. the buildTargets, but I disagree with your specific example about resources. When it comes to sources, resources and classpath entries, my experience with various build tools is that order matters. There is sometimes a fine line between a build that works and one that doesn't, because of some ordering differences. While sets typically can't preserve order, lists can contain distinct entries, so when in doubt, I'd tend to use list. Worst case is, when a run target works in the build tool but no longer works in the IDE because of some entry shuffling. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, I've seen multiple situations that order mattered for example with |
Beta Was this translation helpful? Give feedback.
-
Currently, we use lists as a primary type for storing multiple values. However, it doesn't really make sense to do so, because in many cases the order is unspecified and the results shouldn't contain duplicates. For example, in the resources request the order of URIs in the response has no semantic value. In the new testkit I wrote an order-ignoring json list comparator. However, assuming that every list in the protocol is de facto a set is a dangerous footgun. So I think we need to introduce a distinction between sets and "real" lists, especially if we want to have a reliably working testkit.
Discussion #505 is related, because it regards encoding maps as maps (and not lists).
Beta Was this translation helpful? Give feedback.
All reactions