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.
On Fri, Oct 21, 2011 at 4:13 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> One thing that might help relative to enums is that we can put all of the
> knowledge about what an operation is into the enum so that inconsistencies
> and omissions might be easier to see.
> Regarding whether to use an integer or an enum, I really thought that enums
> weren't much different from boxed integers in any case. We can put the
> necessary integer codes into the enum so it isn't difficult to get the code.
> It is barely conceivable that there is a measurable cost to the boxing, but
> I would be very surprised if so. Many of the accesses as integers are
> switch statements which would work as well as enums (and better because it
> would provide completeness checking).
> Ben, do you have something specific in mind here? Were you referring to the
> boxing/unboxing cost? Or the clarity of the code in question? Or something
> I didn't think of?
> On Fri, Oct 21, 2011 at 3:32 PM, Benjamin Reed <[EMAIL PROTECTED]> wrote:
>> i think you found the bug because you reviewed that code to convert to
>> enum. is there something inherit to using enums that helped? i don't
>> think it is wise to use enum when many (most perhaps) of the accesses
>> need to be integers.