> i was thinking mostly in terms of the code itself. enums are great for
> structures that aren't serialized, but when you do serialize it, you
> end up having to force specific values into the enum and converting
> back and forth during the serialization and deserialization. i find
> that the enums, in this case, just shift the ugliness around.
> i'm also not sure about the performance implication, it should just be
> the cost of autoboxing, but to be honest it's more about the code
> readability to me.
I've updated the patch for ZK-1199 (make OpCode an enum). Please see yourself,
whether you consider the resulting code to be uglier or not. Especially in the
following classes I could remove a couple of lines and complexity:
PrepRequestProcessor, CommitProcessor, FollowerRequestProcessor,
If you're concerned about readability, we should trust Joshua Bloch. One of
the advantages pointed out by him is type safety. The Request class has long
zxid, long sessionId, long cxid, and int type. During refactoring I've had a
hard time to not mix positions of the constructor parameters. The IDE can not
help me to distinguish between different number types.
Thomas Koch, http://www.koch.ro