do y’all consider the order of an enum part of its...

# random

[Shawn]

do y’all consider the order of an enum part of its API? is it unreasonable to think that changing the order of enum values is a breaking change? this question came up in a situation where my team had to add an ordering to a class we didn’t own, and the order as written in the source was exactly what we wanted—`Comparator.comparingInt(ExternalEnum::ordinal)` would have satisfied the constraints today, but we ended up going with a custom comparator because it more clearly described the need for the ordering (and it was unclear if we could rely on the written ordering staying the same)

[Fleshgrinder]

The ordinal value (and thus the position of enum values) is definitely part of the public API. Changes SHOULD be considered breaking.

[louiscad]

In your case, you could also have written tests to check for the enum order to be what you expect/need.

[thanksforallthefish]

still in your case the fact that existing enum are already in proper order does not guarantee new enums added will also be. I can imagine a task enum with NEW, PROCESSING, DONE, then all of a sudden the owners of the enum realizes BLOCKED is missing and adds it at the end so that it does not break the ordinal API, but would still be fine for you to have it as last element?

so I guess what I am saying is, if you don’t own the enum, just go with a custom comparator that gives you business meaning to the order

[Matteo Mirk]

When I create an enum I always make sure that no operation or client usage depends on their ordinal value, to prevent any breakages in the future. I believe it’s very short-sighted and dangerous to consider the order as part of its public API.

[Fleshgrinder]

That's impossible with any library where you are not in full control of all users (e.g. OSS). 😉

[Matteo Mirk]

Still I believe that no sane library should consider constants order as part of its API

[Matteo Mirk]

If you’re dealing with a nasty case fine, I get it. But I think it should be an exception and not the norm

[Rob Elliot]

It is part of the public API though - kotlin.Enum provides an instance public final val ordinal: Int that exposes its position in the enum, and implements Comparable on the basis of that ordinal, allowing you to use it as a Range. It couldn’t be harder baked into the public API of the class.

[Rob Elliot]

I guess the lesson is use a sealed class / interface and objects if you want a closed set of instances with the same type but do not want to maintain an iteration order.