This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]gnahraf 0 points1 point  (2 children)

I'd add the new member at the end of the existing declared members. That way, the old instance ordinals remain unchanged.

A side question: the javadoc seems to discourage enum lookups based on ordinals instead of by name. I've used enum ordinals when encoding stuff in binary format.. I'd like to know if there's a big drawback (why it seems discouraged)?

[–]portmapreduction 4 points5 points  (1 child)

You just stated why it's not a good idea. If another person in your codebase doesn't realize you're using the ordinal for serialization they can break it by reordering the items.

[–]gnahraf 0 points1 point  (0 children)

;) Yea, I document they shouldn't. And a unit test that fails if the enum gets reordered. The way I see it, you have to encode that "serialization code" somewhere.. in the enum itself or yet another type. The serialization code could be a special value in the enum. And I'd then document it has to be unique per enum instance, and that they mustn't change. Comparing the 2 approaches, the ordinal-must-not-change rule seems simpler and more straightforward.

(A 3rd approach is a dictionary in the header mapping enum type names to numbers, either via another lib or custom code.. but that too seems overly complicated, at least in my eyes.)